Hacker News Reader

Comment by dlsym | Hacker News Reader

18ms for calculating Fibonacci numbers from 1 to 10. This is definitily bringing JAVA back to the good old days of enterprise execution speeds. :-)

Really cool proof of concept! I would really enjoy seeing more projects like this!

View on HN

Who doesn't wish it was still 1999? Hot stock market, millenium mania, cheap gas, dot-coms. Really slow Java makes it all come rushing back.

> [1999's] slow Java

Java 1.2 (1998) used a JIT and a generational collector. It was probably faster than today's Ruby, Python, or PHP.

What was slow was start up. Applets in particular were really horrible since they completely froze the browser for several seconds.

If I remember correctly, this was finally fixed many years later with some version of Java 6.0.

It didn't go full speed until Sun released HotSpot, which was probably a year or two later. The farther back in time you go, naturally, the slower Java was, sort of like the universe as you go back to the Big Bang. You also could have made more in the stock market with each receding year. But 1999 was a memorable year.

1999 was right about the time Java starting getting fast enough to use for servers (where you don't care much about start-up time).

About that time, I needed to decide whether to use Java or Delphi (an ahead-of-time Pascal compiler) for a new project. I was worried about garbage collection overhead. So, I designed a trivial benchmark wherein an array of simple objects was constructed in a loop (as we revisit each slot in the array, we replace the old object with a new one). Java came out ahead. The superiority of GC, along with platform independence, convinced me to go with Java.

Highly object-oriented code makes extensive use of memory allocation; I suspect this to be a general rule. Java almost forces you to use this style, so consequently, I expect that the GC is highly optimized for it, and GC is lazy, which cuts the cost of deallocations. I can't see any reason why manual memory management with new/delete, malloc/free, etc, couldn't be done lazy, also, but I think it usually reclaims memory eagerly, and gives a different trade-off (i.e. delete/free are implemented eagerly inside the standard library, rather than just marking the memory and returning). If you want the highest performance, you'll allocate memory in large blocks and take it out of the hands of the GC or library.

PS. I can't swear to it that you could do a decent lazy delete or free and get better performance in C or C++, but it doesn't sound absurd on its face. What the standard library could not do is run its own background thread and update memory structures asynchronously, the way some advanced GCs do. But the whole problem can be avoided by doing fewer allocations in the first place, and performance will be consistently good no matter what the platform.

> JAVA

Why did you spell it in all-caps here?

Everything enterprisey has to be in all caps and mean something that's trying to be cool.

JAVA = Just Another Vague Acronym.

That and you need to use xml for everything to be enterprise.

XML is like violence: if it isn't working, you aren't using enough.

At least now in java things are going from XML to annotations :)

Hasn't that transition been going on for 6+ years now? I guess that's what counts as agile in the enterprise space.

Reply on news.ycombinator.com