Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Newsletter no. 28, March 31st, 2003

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

This month brings you a scoop. Our intrepid reporter has been chasing this story for the better part of a year, and now we can bring you the true story of the creation of Java in this month's interview with James L. Frank. You don't want to miss this!

A note from this newsletter's sponsor

Get a free download of GemStone Facets 2.0 and see how this
patented technology supports JCA 1.0 to seamlessly integrate
with J2EE application servers to enhance performance.

We bring you our usual selection of articles from around the web. Three stood out for me. Firstly, O'Reilly have made available in PDF form chapter 12, "Distributed Computing" from my book Java Performance Tuning. In the current edition this chapter includes optimizing a Java Web service, and it is well worth reading.

The second article that stood out is Steve Trythall's article about optimizing security performance for JMS. Articles that provide useful new tips on security performance are few and far between, so I always find these tend to stand out.

Finally, Intel has produced an article entitled "Enterprise Java Performance: Best Practices". The article itself is quite good, but what makes it stand out for me is the historical context. The last time Intel produced an article covering Java performance (in 1999), it had two tips in it: use Intel chips; and write the code in C using the JNI to call it. Thankfully, Intel is now taking Java more seriously.

Our other regular sections are here too. Firstly, we have that amazing interview about the creation of Java - don't miss it! And our question of the month on Java performance vs the performance of other computing languages will simply astonish you.

We have Kirk discussing various micro-benchmarks, the usefulness of threads, capacity planning, J2EE caching and more in his roundup of discussions; Javva The Hutt researchs JUnit tools for performance testing, and includes his diary; we have a new tool report on Piper, a pure Java caching solution for dynamically generated web pages; and, of course, we have over 100 new performance tips extracted in concise form.

A note from this newsletter's sponsor

Java Performance Tuning, 2nd ed. covers Java SDK 1.4 and
includes four new J2EE tuning chapters. The best value Java
performance book just got even better! Order now from Amazon

Tool Reports


Java performance tuning related news.

A note from this newsletter's sponsor

JProbe helps developers understand precisely what is causing
problems in Java applications - right down to the offending
line of source code. Download a free evaluation of JProbe today.


Recent Articles

Jack Shirazi

The Roundup

I happened to catch the European Figure Skating Championships Dance competition. As should be expected, the German dance couple proved to have the most interesting costumes. They were dressed up as a pair of very strange looking robots. The graphics on the front of the costume appear to have been lifted from perfmon (Microsoft's system performance monitoring tool) proving that performance-monitoring tools are not just for geeks anymore. And now for this months roundup.

The JavaRanch

At the Java Ranch, an innocent question regarding Jikes yielded a few nuggets of wisdom. First, it's been long known that JIKES is much faster at compiling source than javac. One does have to be aware that JIKES can produce different byte code from the same source, which under some circumstances can cause a VerifyError exception to be thrown. As for the nuggets: always compile your code using the compiler that was bundled with the JVM you're planning on using before deploying to production.

Does using static methods offer a performance advantage? If you're using one of the new versions of the JDK, then the compiler will take advantage of the information to in-line the method call. In the posted test, the saving was measured at ~50% ( 420-241) over 100000000 calls. This amounts to 179 ms over 100 million calls or 1.79 nano-seconds per call. But, one should consider the effects of using statics. Objects, by their nature, provide you with isolated pockets of state and behavior. Excessive use of statics breaks this model and will most likely result in a much poorer implementation. In my humble opinion, the design cost associated with this performance strategy far outweighs the benefit.

To StringBuffer or to +. That was the question that was put to the test during a micro-performance benchmarking exercise. The test was simple concatenation of a string in a loop. That the initial test did not yield the expected results, did yield a number of plausible explanations. The time to concatenate String using the + operator was not much different than those where StringBuffer was used. Of course, we all know that the compiler will replace the + operator with the append() method found in the StringBuffer class. One other point: be careful when you under-take a micro-benchmarking exercise as results can easily be misleading.

The Server Side

From the server side, we start with a posting that's asking about the use of EJB 2.0 to bulk load a database. Now, there might be good reasons to use an EJB server to bulk-load a database but most databases come with their own optimized bulk loader. It is doubtful that anything will have better performance characteristics.

It would seem that JCache is finally coming into it's own with a number of vendors offering product. A number of these came out in a thread on the question. Included in the list are Chutney Technologies, Versant, Tangosol and as well as product from one of our sponsors, GemStone.

Here is a question that is often asked but never answered. How much computing capacity do I need to support my application? Why is this seemingly simple question so hard to answer? Consider this. To produce a good estimate, one will need to evaluate a complex set of requirements without having any data on which to base an answer. It's difficult to provide an answer in a vacuum. So, how can one fill the information void? Well, in many instances, the new system is being built to replace an older system. Even if the new system is offering many new features, one can still obtain some information by looking at the hardware being used by the older system. The difference in functionality (between the new and old system) maybe used to calculate the extra capacity needed to support the new features.

From the gaming community, we have a number of questions from a newbie. The most notable asked if using an obfuscator would help performance. Obfuscators do two things to a class file. First, they shrink it by truncating all of the entries in the name space. Secondly, they will do some static byte code optimization. Though the performance impact of each individual change on the class file is unknown, it is commonly seen that obfuscating your classes does result in a performance boost.

In this day and age, you'd think that no one would question using threads in an application. But here there is a long (and sometimes heated) debate on the usefulness of threads in a gaming environment. Yes, there are a group of game developers that were arguing against the use of threads! The interesting part is that you can't dismiss their arguments. First, we can agree that the primary purpose of threading is to maximize the utilization of your hardware resources. For example, if your process is reading data from a source, it typically has to wait for that data to arrive. During that time, the CPU will most likely be idle. Introducing another thread into the mix may allow one to further utilize the CPU. The question is, does the cost of managing threads outweigh the benefits of being able to further utilize a resource (the CPU in this case). You might raise the point that threading allows a process to utilize multiple CPUs in an SMP environment. The argument here is that the target audience is using single CPU and consequently have fewer opportunities to recover the cost of threading. In addition to this, gaming (as well as other computationally intensive activities) already does a good job of fully utilizing the CPU which could very well result in one not being able to recover the cost of multi-threading. So, although the benefits of multi-threading seem intuitive, it appears that there are still instances where highly threading an application may not be the approach.

Finally, there is an extremely long thread questioning why SWING would appear to be so slow. As with most threads of this length, it expanded to include a number of interesting sub-topics, why SWING doesn't take advantage of graphic accelerator cards, color bleeding and blurring, and performance issues with the 2D and 3D graphics packages. What the thread fails to do is identify the exact case of the performance bottleneck in swing. But, there are plenty of clues. For instance, SWING takes very little of the CPU. Even though SWING creates a lot of garbage, the collection of that garbage does not seem to present a problem. The machine being used had enough memory that the OS was not swapping pages. The animation was not doing any input so that was ruled out. It was finally speculated that SWING batches repaint calls that get fired on a periodic basis. If this is true, then one has to wonder why SWING is attempting a server optimization on a client. My hypothesis is that there might be a class that is either ignoring or missing a signal that causes SWING to stutter. What was most interesting was watching how each hypothesis was evaluated on it's merits and then tested. The results drew a conclusion that in every case proved the hypothesis to be false.

It would seem that blogs are all the rage. Don't feel left out if you don't know what a blog is, the rage is still young. Think of a blog as an online diary that you get to share with the world. How is this different than having web pages? Well, one of your peers can add comments to you blog. How is this different than the Wiki? The differentiation here is a bit thinner but wiki is a more publicly owned forum than a blog. If you're interested, my blog is at is hosted by N-ARY, a consulting firm in Scotland operated by the venerable Alan Williamson.

Kirk Pepperdine.
Kirk blogs at

Javva The Hutt

Robert Martin has been writing a series of episodes with a couple of XP developers building various things. I was reading the Once Is Not Enough episode. Quite a nice article, you get introduced to two difficult concepts, network programming and multithreaded race conditions, for the price of one article. Efficient.

Open-source Java tools

I'm always on the lookout for freebie tools. They're so easy to buy, and good for the budget. And it's not like the old days when management decided free meant no support so no way would they put it on "our" machines. Anyone out there remember how desperate the admin guys were to have Perl pre-installed before purchase so that they didn't have to justify installing and using freeware? If it came with the machine you could use it, if it didn't then the struggle was uphill all the way. Now, open-source is accepted, and even preferred in many places. Bryan Dollery has a whirlwind tour of open-source Java tools. Articles like this help keep me up to date on what's available. Useful.

When he mentioned a JUnit extension that looked handy for performance testing, I thought I'd have a look see at what else you can get JUnit compatible that's good for performance testing. There were quite a few:

Only JUnitPerf is really specifically targeted at performance testing, but the others could come in pretty handy if you need to build load test stuff.

Diary of a Hutt

February 5. It's time to build up my team. Apparently, apart from first disciple Boris, I'm to have two more followers. One to join ASAP, the other as per needs or earlier if someone perfect comes along. Soo, its time to brush up on interview technique. I think a few questions on performance are naturally in order. Let's see:

As you can see, I've gradually increased the complexity of the questions to challenge the the candidates.

February 12. It seems that we're in a deepish recession (in IT at least). Our HR department asked me to produce as detailed a technical job specification as I can. They say that if they advertise in the current market they'll get too many CVs to wade through unless we rule lots of people out by requiring lots of very specific technical qualifications or experience. Sympathy, the HR gal handling my requirements told me that they recently got over 2,000 CVs for an open Java post (I think it was Frezian's expansion position, so probably anyone could do it. Frezian hasn't really got a strong grounding in Java, who know what he specified). HR had decided that rather than wade through the CVs, they would simply readvertise the position with more technical requirements. Apparently this had got it down to a more manageable 300 or so CVs. Even so, that's a lot of time spent reading CVs and weeding out candidates. I asked them if I could have a look at these CVs, maybe there was an appropriate candidate. Then I calculated that if I spent ten minutes on each CV, that works out to 50 hours reading CVs. I'd be doing nothing else except essentials for a week! Of course, I'm more efficient than that. I gave them to Boris.

Boris surprised me. He came back the next day with three candidates. I couldn't believe he'd been thoroughly through over 300 CVs in one day, so I had a good look through those three to see if they were appropriate. As entry level candidates they were okay, but not really great picks. Then I realized what Boris had used as a filter. "Boris, I'd like you go through the CVs again and find some more candidates. Oh, and Boris ... this time please, don't restrict your choices exclusively to Russian speakers."

February 19. Boris's second outing through CV land produced a similar crop of candidates to his first, okay but not great candidates. I decided, like HR, that we might as well advertise the specific position rather than start looking at Frezian's generic cast-offs.

February 24. Bill Venners has published an article about How to Interview a Programmer. I liked the idea of asking for a code portfolio, though I'd probably ask for highlights to be identified and explained by the candidate rather than simply look through the portfolio. I also liked Chuck Allison's technique of asking for the best of what they've done:

I've asked what they've done that they're the most proud of. This usually reveals the depth of one's understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.

February 26. That went well. I used Sympathy as much as possible, pleading my inexperience to get her to do as much dirty work as poss. Then I made Boris do almost everything else. My second disciple, Brainshrii, is due to start in a few weeks for a trial period. I couldn't understand half of what he said during his interview, but the half that was intelligible was very good. He taught me a couple of things, and had a fantastic grasp of all aspects of Java performance. HasntGotAClue interviewed him too, since technically he is in HasntGotAClue's department. When he came along to discuss him, HasntGotAClue said "I don't think he has the right mix of customer facing skills". That's management-speak for not presentable enough, or in this case another way of saying "I couldn't understand him." I wanted him and don't like my decisions to be queried by HasntGotAClue, so I pointed out he had exactly the skillset I wanted, that he would be back-office, and then pushed the money button. "You know he is tight with a good sized Indian outsourcing Java specialist. If we ever need to outsource, he would come in very handy as a contact point". Complete bunk of course, but HasntGotAClue hadn't understood anything the guy had said, so how was he to know.


Javva The Hutt.

The Interview: James L. Frank, Java's genesis

There have been various different stories put out about how Java came into existence. I can reveal that these are generally made up stories. The reality is far different and, for the first time, I can reveal the full true story.

It started in early 1990 when two senior marketing directors from Sun Microsystems were busy brainstorming for future directions that Sun should take. James L. Frank and Bobby Stein quickly decided that what Sun needed was a hot new programming language. They had seen Microsoft make millions from continually altering Basic, C, and C++, and realized that Sun needed a language they could call their own if they really wanted to play with the big boys. Frank and Stein quickly realized they needed the big three things that every programming language has: a father; a name; and something cool. So they started with the father of their "hot" new language.

"We wanted someone with a name that would give a feel for the language, so we started thinking about the qualities we wanted in the language" said James Frank when I interviewed him about the genesis of Java.

"We came up with three core touchy feely words. We wanted the language to feel fresh, fun, and rock solid. Then we started looking around for the name of a Sun employee that would fit the bill. We started looking for a guy called Rock Fun-Fresh, Fun Fresh-Hard, or something like that. HR [the Human Resources department] couldn't find anyone with that kind of name, so we went back to the drawing board. Then, we suddenly realized we could go for several names, which would make it much easier. So we started with Fresh. No Fresh, but we started thinking laterally, you know, something like New, or maybe Baby. Bobby suddenly remembered he once saw something about a guy called Cygnet [a baby swan], but we couldn't track him down. But HR said there was some guy called Gosling [a baby goose] and we thought, what the hell, let's start there."

Frank continued "We tracked this guy Gosling down to the I.T. department, which was a pretty good omen. He turned out to be a QA [quality assessment] tester, but that wasn't a problem for us. After all, it wasn't like he'd really have to invent Cool."

At that point, I queried what Frank meant by "not needing to invent Cool".

He replied "Oh yeah, Bobby and I were calling the language "Cool" at that point. We needed a working name, and that pretty much summarized what we wanted it to feel like. I lived with that name for so long, I still use it. Later on, we went through so many different possible names that it would fill a book. But I'm getting ahead of myself here. At this stage we had only just chosen the father of the language. Of course we knew we'd have to invent some background for the guy, but that would also come later. Next we looked for "Fun". And would you believe it, there was a hugely talented software engineer called Brian Fun here at Sun. He was even in the same building as us. We met him, and talked to a few guys he worked with. We couldn't believe it, this guy was everything we wanted. His colleagues pretty much made him out to be a genius. We had struck pay-dirt. This guy could actually play the part we wanted."

"Finally we looked for the last of our triumvirate. We knew we'd never find someone called Rock Hard, which was our ideal name, and for a while we toyed with the idea of just creating the character but never letting him get seen. But ultimately, we wanted flesh and blood. So we got the thesaurus out and started trying alternatives. Eventually we had a list of Stone's, Steel's, Wall's and a couple of other names that I forget. We actually had too many candidates. So first we decided that of the choices we'd prefer Steel, it had just the right kind of feel of being "hard" that we wanted. Then we chose one of them. He was actually a "Steele" with an extra "e" on the end, but he scraped in because this guy had actually created a language before, I think it was called Devious or Schemer or something, and had even written a couple of technical books too."

I realized that Frank was referring to Guy Steele Jr., the co-creater of "Scheme" and also known for his reference books on "Lisp" and "C".

Frank continued "So now we had our guys, we needed a name for our language. We agonized over that name for weeks. Place names, plant names, animal names, made up names, colors, textures, senses, smells. Eventually we gave up and decided to use a working name. We wanted to stick with "Cool", and did between me and Bobby. The other guys wanted to call it "Sellotape". We knew that if that ever got out there could be hell to pay. So we steered them to something a little more innocuous. I think we started suggesting flowers first, but moved on to trees fairly quickly. I mean these were a bunch of nerds. Could you see them working on something called "Tiger-lily"? I can't remember who came up with "Oak", but we all knew that was right when we heard it. Simple, solid, uncontroversial."

"Now came the hard part. Bobby and I went through some old questionnaires about customer requirements for languages, then we compiled a new one and sent it out to a few dozen people we knew. We basically asked the question "If you were going to invent the coolest programming language that has ever existed, what would you put in it?" I can tell you, some of these guys were from Mars, and I don't mean as opposed to Venus. These guys wanted everything. It would work on any computer. It would have an easy to build GUI interface, consistent on any type of computer! It would be completely secure. It would understand networking and be able to run across the Internet. It would be able to run a program that wasn't even installed on the computer. Well, I can tell you when we saw these answers, Bobby and I realized we'd been too ambitious. While we thought about what would be practical for Oak, we passed on the questionnaire results to the other guys. Two weeks later, we called a meeting to go over what Bobby and I had come up with. To our amazement, in the intervening time, Brian [Fun] had built a prototype covering most of the list of desired features from all those off-the-wall questionnaire answers! At this point, we knew we had something really hot. I called the hotline."

"The hotline?" I broke in. "What is that?"

"At Sun, we have a special number you can call if there is something important happening" said Frank. "Actually, most of the time, the hotline operator sends the call through to us in marketing, because it's the kind of stuff we're interested in using. But this time, we were making the call. I got through to the operator, told her that we had an important new product in genesis, and then I was told to wait. Ten minutes later, the meeting room door opened, and this guy in a tux with a martini in his hand walks in and says "Joy. Bill Joy".

We had gone straight to the top, and got hold of Bill Joy [a founder of Sun]. We gave him the full scoop. In the following weeks he got heavily involved with Brian. They used to get locked away, god knows where, for weeks. We used to refer to them all the time as "Fun & Joy". Then, one day, Brian disappeared. Bill said he'd gone over to SpNeXTre where they had a lot of Jobs, but I never heard anything about him again. Bill told me to re-write any marketing material we might have, to eliminate Brian from the whole story. Fun had gone from the project. Even though there was still Joy, I didn't feel like being involved any more. Soon after, I left Sun and went into partnership with my girlfriend Vivian Leigh and my friend Tim Madeah."

I had heard of his company, and knew that as they were a Microsoft partner, Sun had a policy of not doing business with them. So I asked him "Does it bother you that Sun never gives any business to Frank, Leigh, Madeah?"

"I don't give a damn!" was his reply. "Where we do business, Sun doesn't shine."

A few months after interviewing James Frank and discovering the true story of Java's creation, I managed to catch up with Bobby Stein. I still had one piece of the story missing, how the name "Java" was chosen. At first Stein refused to say anything to me. But after I revealed what Frank had told me, he decided to speak. We met in an underground car park in San Francisco. He sat in a dark corner, wearing a coat with a hood up. "I'll deny I ever met you if you say I told you this" were his first words to me. In the interests of journalistic truth I've included everything here, but I implore any readers of this account to avoid telling anyone that my source was Bobby Stein.

"It was a few years into the project. We were still calling the language "Oak", and were looking for a better name. At the time, we had a bunch of people working on the language. We were getting a bit anxious about James Gosling. He was really clueless, couldn't seem to understand the basics of our new language. Since he was the one we'd picked to be the father of the language, we had to do something. So we started having him tutored. Every day he'd get some tutoring on an aspect of the language, then he'd have to write an essay showing his understanding. The essay was always wrong. His tutor would mark the essay, and started writing "Just another vain attempt" on the paper because he was getting really fed up. After a couple of weeks, he shortened it to the acronym JAVA. I had this pile of essays on my desk, and every once in a while I'd flick through them and see "JAVA" written on the bottom in big red letters, and I guess it grew on me." Stein had finished his account.

"So there is no relation to coffee or the Indonesian island?" I asked.

"That's right." he said. "In a way, you could say it was all down to James. If he had understood those lessons instead of being the complete dunce he was, the Java language might well have been called "Excellent"".

(End of interview)
April 1st 2003

Jack Shirazi

Question of the month: Java speed compared to C, C++, C#, Perl, ...

How does Java" performance compare to C/C++/C#/Perl/VB/FORTRAN/(any language of your choice)?

Next month's Question of the Month deals with whether this was a valid benchmark. You may wish to read it first

Extraordinarily, the Java JIT Compiler optimization which enabled this benchmark to work as listed here has been backed out in version 1.4.2 of the JDK. So sadly, this benchmark only works with 1.4.1 JDK, which unfortunately makes this already controversial page somewhat useless.

If you search the internet for comparisons of Java against other languages, you will see many advantages Java has. Cross platform portability, ease of development, garbage collection, a strong security model, and much more. But the most important feature is almost never mentioned. Java is by far the fastest computer language ever invented. I'm not talking 10% faster. I'm not talking 50% faster. I'm talking hundreds of times faster than any other language. This is hugely simple to demonstrate, with a test anyone can perform on any machine. In any language, simply time how long it takes to run a simple empty loop for a very large number of iterations. You can't get a simpler test than that! Here are the results for a few languages, using a loop iteration count of 10 000 billion iterations:

LanguageTime taken to run a simple empty loop test for 10 000 billion iterations
JavaUnder one second
Perlapprox. 1 month
C/C++approx. 1 month
C#approx. 1 month
Assemblerapprox. 1 month
Fortranapprox. 1 month
Adaapprox. 1 month
Basic (e.g. Visual Basic)approx. 1 month
You name itapprox. 1 month or greater
Other languagesapprox. 1 month or greater

Naturally, these results are astonishing. But don't take my word for it. Run the test yourself. In the next few sections I provide source code and methodology for the test in several languages. You can see by reading through these sections that there is no complexity involved in running the test in any language.

Java benchmark

1. Create a simple test class which times a loop. The Java definition is

public class Loop
  public static void main(String[] args)
    //10 000 billion iterations
    long time = System.currentTimeMillis();
    int REPEAT1 = 1000 * 1000;
    int REPEAT2 = 1000 * 1000 * 10;
    for (int i = 0; i < REPEAT1; i++)
      for (int j = 0; j < REPEAT2; j++)
        //do nothing
    time = (System.currentTimeMillis() - time)/1000;
    System.out.println("Time taken: (in seconds) " + time);

2. Compile this class. In Java this is done with the command


assuming the previous Java class definition is saved in a file called

3. Run the test. I use java version 1.4 running in server mode as follows:

java -server Loop

Perl benchmark

1. Create a simple test which times a loop. The Perl definition is

#10 000 billion iterations
$REPEAT1 = 1000 * 1000;
$REPEAT2 = 1000 * 1000 * 10;
for($i=0; $i<$REPEAT1 ;$i++)
  for($j=0; $j<$REPEAT2 ;$j++)
    #Do nothing
print "Time taken: (in seconds) ",$time, "\n";"

2. Run the test. Assuming the previous Perl code definition is saved in a file called loop.perl, the test is

perl loop.perl

C# benchmark

1. Create a simple test which times a loop. The C# definition is

using System;
class Loop
  static void Main()
    DateTime start = DateTime.Now;
    int REPEAT1 = 1000 * 1000;
    int REPEAT2 = 1000 * 1000 * 10;
    for (int i = 0; i < REPEAT1; i++)
      for (int j = 0; j < REPEAT2; j++)
        //do nothing
    TimeSpan time = DateTime.Now - start;
    Console.WriteLine("Time taken: (in seconds) {0}", time.TotalMilliseconds/1000);

2. Run the test.

csc loop.cs

C/C++ benchmark

The following test can be used to test both C and C++.

1. Create a simple test which times a loop. The C/C++ definition is

#include <sys/time.h>
main(int argc, char *argv[])
  int i, j, REPEAT1, REPEAT2;
  struct timeval before, after;
  void *tzp;
  /*10 000 billion iterations*/
  tzp = 0;
  before = (struct timeval*) malloc(sizeof(struct timeval));
  after = (struct timeval*) malloc(sizeof(struct timeval));
  gettimeofday(&before, &tzp);
  REPEAT1 = 1000 * 1000;
  REPEAT2 = 1000 * 1000 * 10;
  for (i = 0; i < REPEAT1; i++)
    for (j = 0; j < REPEAT2; j++)
      //do nothing
  gettimeofday(&after, &tzp);
  printf("Time taken (in seconds): %ld\n",

2. Compile this class. In C/C++ this is done with the command

<compile> loop.c

assuming the previous C/C++ code definition is saved in a file called loop.c, and replacing <compile> with the name of your compiler, e.g, gcc, cc, etc

3. Run the test.


The team

Servlets, stateless session beans, or both? (Page last updated February 2003, Added 2003-03-31, Author Kyle Gabhart, Publisher IBM). Tips:
Choosing A Collections Framework Implementation/Providing a Scalable Image Icon (Page last updated February 2003, Added 2003-03-31, Author John Zukowski, Publisher Sun). Tips:
Thread safety (Page last updated February 2003, Added 2003-03-31, Author Vladimir Roubtsov, Publisher Javaworld). Tips:
Optimizing (Page last updated February 2003, Added 2003-03-31, Author Ted Neward, Publisher Ted Neward). Tips:
HttpSession Objects (Page last updated January 2003, Added 2003-03-31, Author Brian Russell, Publisher JavaDevelopersJournal). Tips:
JVM Shutdown Hooks (Page last updated January 2003, Added 2003-03-31, Author Frank Jennings, Publisher JavaDevelopersJournal). Tips:
Optimized web services (Page last updated January 2003, Added 2003-03-31, Author Howard D'Souza, Publisher WebservicesDevelopersJournal). Tips:
J2ee best practices (Page last updated January 2003, Added 2003-03-31, Author TheMiddlewareCompany, Publisher TheServerSide). Tips:
JMS security options (Page last updated February 2003, Added 2003-03-31, Author Steve Trythall, Publisher JavaDevelopersJournal). Tips:
Submillisecond precision from Java (Page last updated January 2003, Added 2003-03-31, Author Vladimir Roubtsov, Publisher JavaWorld). Tips:
Stack Trace Decoding (Page last updated January 2003, Added 2003-03-31, Author Heinz Kabutz, Publisher JavaSpecialists). Tips:
Chapter 12 of "Java Performance Tuning", "Distributed computing". (Page last updated January 2003, Added 2003-03-31, Author Jack Shirazi, Publisher O'Reilly). Tips:
Create objects in scope (Page last updated February 2003, Added 2003-03-31, Author Ashutosh Shinde, Publisher DevX). Tips:
Enterprise Java Performance: Best Practices (Page last updated February 2003, Added 2003-03-31, Author Kingsum Chow Ricardo Morin Kumar Shiv, Publisher Intel). Tips:

Last Updated: 2024-06-30
Copyright © 2000-2024 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us