Kyle Brantley: July 2009 Archives
While I am no huge fan of Google Chrome, at least one aspect of it has seriously impressed me - the JavaScript engine.
Over the summer, to help with the prevention of boredom, a friend and I sat down and decided to make a game. This game lives in the browser. He's writing the client (browser) side code, I'm writing the server side code.
And, like geeky college students, we are doing things that Probably Should Not Be Done In A Browser - 1024-bit RSA encryption (to the server) and signature verification (from the server). Used sparingly, this isn't a real issue... until you send status update requests to the server every second and a half, at which point it proves to be problematic. I'd imagine that this is at least partially because JavaScript has no native BigInteger implementation, which means that for a browser, you have to make one yourself... in JavaScript.
I've compared a few browsers side by side on my own machine with SunSpider, the javascript benchmarking suite. Firefox 3.5 with the JIT compiler enabled matches the Chrome engine in a lot of tests, beats it in others. Chrome, the same. It is generally a pretty equal test, with Chrome in general being a fair bit faster, but never to the point of me seeing it as a massive generational speed increase.
A bit of information:
As I said, we noticed... responsiveness issues. I went to investigate, when I realized that my copy of Firefox that wasn't within the VM was doing the same thing...
Talk about optimization.
While Chrome may not have another user (I quite enjoy Firefox, and having tabs on top of the URL bar really bugs me), at a bare minimum it has seriously impressed me.
Over the summer, to help with the prevention of boredom, a friend and I sat down and decided to make a game. This game lives in the browser. He's writing the client (browser) side code, I'm writing the server side code.
And, like geeky college students, we are doing things that Probably Should Not Be Done In A Browser - 1024-bit RSA encryption (to the server) and signature verification (from the server). Used sparingly, this isn't a real issue... until you send status update requests to the server every second and a half, at which point it proves to be problematic. I'd imagine that this is at least partially because JavaScript has no native BigInteger implementation, which means that for a browser, you have to make one yourself... in JavaScript.
I've compared a few browsers side by side on my own machine with SunSpider, the javascript benchmarking suite. Firefox 3.5 with the JIT compiler enabled matches the Chrome engine in a lot of tests, beats it in others. Chrome, the same. It is generally a pretty equal test, with Chrome in general being a fair bit faster, but never to the point of me seeing it as a massive generational speed increase.
A bit of information:
- We're using the pure JavaScript RSA and BigInteger library from ohdave.com/rsa. I make no claims to the speed of efficiency, and I have no real benchmarks of just this library, either. We searched "rsa javascript" and went with the first link we found on Google. We have not investigated optimizing this, though we probably should.
- The actual requests and responses are pretty small - no more than 300 bytes after the initial data loading.
- These requests occur every 1.5 seconds, but we'll likely increase that down the road.
- The testing was done in a VM running a 64-bit copy Windows Vista. The VM host is an Intel i7 920 running qemu-kvm (or, it is a really fast VM, thanks to CPU virtualization extensions.).
- Browsers: Firefox 3.5.1 with the JIT compiler enabled; Google Chrome 2.0.172.37; Safari 4.0.2; all under Windows Vista - all being the latest version available. (I wish I could have tested Opera too, but it has a very very strange bug involving the RSA.)
- I'm going to say "99% CPU," "10% CPU," and so on. Task Manager splits the load percentage over every core on the machine, and the i7 has 8 that it detects. However, as stated, this was done in a VM, which I allocated a single CPU to. "99% CPU" is going to mean "hey this app just froze on me and took most of the OS with it."
As I said, we noticed... responsiveness issues. I went to investigate, when I realized that my copy of Firefox that wasn't within the VM was doing the same thing...
- Firefox jumps from 99% CPU 'down' to 65% CPU as reported by Vista's task manager. On occasion it hit 0, but only for very brief periods of time. The RAM usage was also fun to watch: over a period of many requests, it would mostly remain stable - only to jump by 80MB or more for several seconds, and then back down. This resulted in every three out of four keystrokes being lost, on average, never mind the huge memory churn.
- Safari sat there and looked at us funny.
- Chrome shocked my friend and I. Sure, we had heard that it was fast, and I had done a bit of reading on it. However, I was quite surprised when I saw that it was using a maximum of 10% CPU and roughly 18MB of RAM without any spikes in either. Wow.
Talk about optimization.
While Chrome may not have another user (I quite enjoy Firefox, and having tabs on top of the URL bar really bugs me), at a bare minimum it has seriously impressed me.
