100ms. Perceptually, the time it takes for a newline. I was really struck by that. I've felt that waiting for 5 seconds for an ant/java compile was too long (use time ant, like Rob - ant under-reports) but thought I was just being impatient. I mean, it's not enough time to even start a sword-fight. However, hearing Rob Pike (who, by the way, looks way too young to be the C/unix legend from the beginning of time that he is) say 100ms was their target for compiles in this talk made me take it seriously.
So, I hacked together a "javac server", that accepts filenames and compiles them. It doesn't exit between compiles, so it only pays the java-start-up cost once (about 2.5 seconds), and then it drops to about 0.5 a second or so. And then, after a few executions, JIT kicks in, and gradually gets even faster - typically between 100ms and 200ms for a compile (though quite often below the magical 100ms barrier).
Bonus 1: In unix, I used rlwrap, which gives you bash-editing features (from readline) to your own programs, and I discovered that the "-c" option enables tab-filename-completion! It becomes almost as easy to use as the shell. This made me so happy, I had to clap for joy, rlwrap is amazing. The only lack is no * , ?, [], {a,b} etc.
Bonus 2: I made it also run the code. A problem I found was that in Java, a class is only loaded once, so if you recompile the source, and reload it... you still have the first one. The only way to overcome this I found was to create a new classloader each time, that hadn't already loaded that class (a gotcha: be careful that this new classloader does not delegate to classloader that already has loaded that class).
Including bonus 2, this gave a combined compile-and-run time average <200ms (about 190ms). Basically negligible. In fact, the first few times I used it, it felt like nothing had happened, and I had to carefully check by deleting the .class file etc... that it really was compiling in that eye-blink. It was amazing. I'll stress this: it is actually faster than just running the code. I found java takes 450ms on average, and now it's running and compiling in 190ms (it's because java also has that startup cost).
That is, it's now twice as fast to both compile and run as just running it.
The magic I discovered is that there's now no need to have separate text files for input, and the infrastructure of parsing, reading directories, etc. You can play with your code by writing snippets of code, and it feels instant. It feels as responsive as an interpreted language like Python or lisp in a REPL.
Going from 5 seconds to <200ms has really made me happy - not just the figures, but the feel of it - and brought more joy into coding. I guess x20 faster is going to have an impact.
2 comments
[ 3.8 ms ] story [ 23.1 ms ] thread100ms. Perceptually, the time it takes for a newline. I was really struck by that. I've felt that waiting for 5 seconds for an ant/java compile was too long (use time ant, like Rob - ant under-reports) but thought I was just being impatient. I mean, it's not enough time to even start a sword-fight. However, hearing Rob Pike (who, by the way, looks way too young to be the C/unix legend from the beginning of time that he is) say 100ms was their target for compiles in this talk made me take it seriously.
So, I hacked together a "javac server", that accepts filenames and compiles them. It doesn't exit between compiles, so it only pays the java-start-up cost once (about 2.5 seconds), and then it drops to about 0.5 a second or so. And then, after a few executions, JIT kicks in, and gradually gets even faster - typically between 100ms and 200ms for a compile (though quite often below the magical 100ms barrier).
Bonus 1: In unix, I used rlwrap, which gives you bash-editing features (from readline) to your own programs, and I discovered that the "-c" option enables tab-filename-completion! It becomes almost as easy to use as the shell. This made me so happy, I had to clap for joy, rlwrap is amazing. The only lack is no * , ?, [], {a,b} etc.
Bonus 2: I made it also run the code. A problem I found was that in Java, a class is only loaded once, so if you recompile the source, and reload it... you still have the first one. The only way to overcome this I found was to create a new classloader each time, that hadn't already loaded that class (a gotcha: be careful that this new classloader does not delegate to classloader that already has loaded that class).
Including bonus 2, this gave a combined compile-and-run time average <200ms (about 190ms). Basically negligible. In fact, the first few times I used it, it felt like nothing had happened, and I had to carefully check by deleting the .class file etc... that it really was compiling in that eye-blink. It was amazing. I'll stress this: it is actually faster than just running the code. I found java takes 450ms on average, and now it's running and compiling in 190ms (it's because java also has that startup cost). That is, it's now twice as fast to both compile and run as just running it.
The magic I discovered is that there's now no need to have separate text files for input, and the infrastructure of parsing, reading directories, etc. You can play with your code by writing snippets of code, and it feels instant. It feels as responsive as an interpreted language like Python or lisp in a REPL.
Going from 5 seconds to <200ms has really made me happy - not just the figures, but the feel of it - and brought more joy into coding. I guess x20 faster is going to have an impact.
10ren