When I first started working at Amazon, a change to one of their low-level libraries would trigger a rebuild that could take a week to recompile all affected packages. My focus was improving their build times. One build tool, used to convert IDL-like descriptions to code, and might be invoked a hundred times for a given library, was written in Java. For the hell of it, I wrote a program in C++ that would produce the same output for a given input. It could be invoked eighty times for each single invocation of the original Java program. So when some Java apologist suggests that "Java is as fast as C or C++", they always fail to mention the head start you need to give them (note the speed tests in the Computer Language Shootout are for Java Server, which means I have to have the damn virtual machine running and taking up memory even when I am not using it).
Ultimately the solution to Amazon's build times involved dependency analysis and parallelization in a multi-machine build farm. But I stand by my hatred of all current virtual machine implementations. Anyone who writes a command line tool in Java, Smalltalk, Lisp, C#, or any other language implementation that takes longer to start up than actually compute the solution should be castrated so that their defective genes are not passed on to future generations.
How about a virtual machine that did some partial evaluation to reduce the solution to something that didn't require the entire 'X' class library? In other words, a compiler that created a new smaller virtual machine based on the input text. Of course, in dynamic languages, if the evil "eval" is used, then you need to include everything. But how many real programs need this?
No comments:
Post a Comment