onkeypress and onkeydown firing rate
Did a little benchmarking, and found this out: JavaScript Events onkeypress and onkeydown fire at the same rate. They fire 16 times per second, or about once every 267 milliseconds.
Why this benchmarking? If you’re using either onkeypress or onkeydown to trigger some action in your JavaScript code, you could wind up triggering that action 16 times in a second. What if it’s a request that triggers some DB processing or an expensive UI action (like creating a closure with a potential memory leak)? That’s something you should avoid. Solutions?
- Use onkeyup to trigger your event. It fires once only, when the key is released.
- Create a flag which your onkey… function checks before executing. The first call sets the flag; before it returns, it unsets the flag. In the meantime, you won’t run (and re-run) expensive operations over and over.
Either way, watch out for the “spamminess” of these Events, and how often they fire.
technorati tags:javascript, events, onkeypress, onkeydown, onkeyup
June 28th, 2007 at 11:55 pm
In windows, you can manually set the repeat rate for holding down the key. I don’t know if the browser (and if javascript) obey that, but I think the firing rate may be more variable than this.
And while I haven’t checked, I bet the event handlers inside something like prototype or jquery implement something like the latter solution.
June 29th, 2007 at 7:55 am
I agree that these are a really rough estimate and are totally variable. (And, my testing methodology was by no means the best
).
In some testing on other machines, I wound up with something like 18 per second, which is still pretty close to the 16 on my original test run. My home machine has the repeat rate cranked all the way up to the max and fires 18 per second, so perhaps that’s the upper boundary?
A scan of the YUI docs doesn’t turn up anything on Event “threading” like this, and my experience with YUI leads me to believe that they don’t “thread” events like this. I don’t think Dojo does either. (Correct me if I’m wrong though).
In the end, firing off 16-18 Events a second in roll-you-own code is definitely something to keep in mind.
July 1st, 2007 at 11:05 pm
Definitely. I tried this out just now using firebug (so much functionality in there!)
Inspect an element like a text input. Then when you’re looking at the element in the HTML view, right-click and hit Log Events. Switch over to Console. Then click into the box and hold down a key.
I didnt expect to see both keydown and keypress firing together (shouldn’t keydown fire once to match keyup? silly standards..), but they were!
Very interesting though.
July 2nd, 2007 at 11:30 am
I agree on FireBug! I used “console.log()” to log the events firing in my test. I didn’t know about “Log Events” though; that’s definitely sweet!
onkeydown and onkeypress have now been rendered functionally equivalent in all major browsers and will fire at the same time; they didn’t used to be, and I agree that they shouldn’t be, too.
However, I’m not really sure what the semantic difference between a keydown and a keypress would wind up being, and coding for a third event state (down, press, up) would create some pretty odd conditions. (Is it down and still pressed? [Giant while loop while pressed]. Now it’s up!]