views:

75

answers:

6

Is there a good resource to get run times for standard API functions? It's somewhat confusing when trying to optimize your program. I know Java isn't made to be particularly speedy but I can't seem to find much info on this at all.

Example Problem: If I am looking for a certain token in a file is it faster to scan each line using string.contains(...) or to bring in say 100 or so lines putting them to a local string them performing contains on that chunk.

+5  A: 

AFAIK, there are no standard benchmarks for the API methods, and in fact, there could be various implementations based on the JVM you are running. Couple that with the JVM's JIT optimizations, garbage collections, and a lot of other things, and I doubt you could get globally meaningful numbers. Most you can do is write your own benchmarks.

Some methods specify the computational complexity of the operations in their JavaDocs. Some other methods describe other performance concerns. Make sure you are aware of them and heed them.

But beyond that, most chances are that you are doing premature optimizations. Use a profiler to see it is actually a bottleneck.

For instance, in your case there will be the cost of reading from a file, the cost of placing strings in the large buffer, etc. I'm not sure you can really optimize by reading at the string level. IF this was really mission critical you could read character-by-character and implement a smart matching algorithm without ever creating strings, this might be slightly faster.

Uri
+1 for mentioning JIT optimisations - a "naturally slower" method that gets inlined/optimised by HotSpot will likely be much faster than a theoretically more efficient one. And since these optimisations happen based on the runtime profile, and I believe the code locality, there's no way to say definitively that "`X` is faster than `Y`, period." And of course you're right - don't optimise prematurely; write clear concise code first and rewrite for speed *if shown to be* necessary.
Andrzej Doyle
+1  A: 

There is no documentation, since it will vary considerably from machine to machine, OS to OS. To get accurate timings for your program, use a profiler. The NetBeans profiler is good.

As to finding out which is the fastest, there is no better alternative then to code both. Alternatively, you might code the simplest alternative, and when it's working, you might discover that it's fast enough for you needs, and not bother coding the more complex implementation.

mdma
+3  A: 

You're looking for a profiler

OscarRyz
+1  A: 

If I understand your question correctly, your asking if it's better to read a line from somewhere, or to read a line from memory. It will always be faster to have the text loaded into memory to do your scans then to read them from an I/O stream, especially from disk. The speed of the read has nothing to do with Java, but how fast the source can get that data to your program.

Jim Barrows
+1  A: 

I agree with ideas about using a Profiler - but you might also want to consider just using log4j (or Apache Commons Logging etc) to get some cheap stats about program performance - in that the log entries in the resultant logfiles will get timestamped to the nearest millisecond: Since logging is generally a useful thing to do when debugging anyway, it's probably worth doing this first.

Learning profiling tools and learning how to interpret the resultant data is usually a non-trivial task in of itself - worth doing , but you might be able to get a rough idea more quickly just using logging data - especially if you format it as CSV etc so you import to a spreadsheet.

monojohnny
+1  A: 

if we overlook disk IO time, and just consider the CPU time spent in your code, the 2nd choice will be much slower than the first.

irreputable