Bug Tracker

Modify

Ticket #1871 (closed bug: fixed)

Opened 6 years ago

Last modified 5 years ago

fix() in event propagation is slow

Reported by: olau Owned by:
Priority: major Milestone: 1.2.4
Component: event Version: 1.2.1
Keywords: Cc:
Blocking: Blocked by:

Description

The fix() function called when an event is propagated deep copies the event to be able to set a few attributes. Unfortunately, the event object is quite large so this is really expensive for events like mousemove. On my 950 MHz PIII wiggling the mouse when an empty callback is set with mousemove() uses up 100% of the CPU time in Firefox.

There's a longer discussion on the mailing list here:  http://groups.google.com/group/jquery-dev/browse_thread/thread/cc768c85d5514098

I've tried shallow copying the event with "for (v in originalEvent) event[v] = originalEvent[v];", but it's still slow.

The only solution I can think of is to copy a couple of documented standard values from the event object, normalizing them as needed, and then let people access the browser event object with an originalEvent field. If you can tell me which values to copy, I'd be happy to supply a patch.

Attachments

1871.diff Download (918 bytes) - added by davidserduke 6 years ago.
possible patch
jquery_test.html Download (975 bytes) - added by davidserduke 6 years ago.
used with FireFox and FireBug profiling to test mousemove event speed

Change History

Changed 6 years ago by davidserduke

possible patch

comment:1 Changed 6 years ago by davidserduke

This patch uses Ariel Flesler's idea (posted in the above jquery-dev thread noted above) of prototype inheritance to clone the event node when possible instead of using extend(). It falls back to extend() when/if it fails like it seemed to do in my IE7 tests.

There are all sorts of possible side effects but it definitely sped up the event code during mousemove in my limited tests.

Changed 6 years ago by davidserduke

used with FireFox and FireBug profiling to test mousemove event speed

comment:2 Changed 6 years ago by davidserduke

Unfortunately metaKey will be changed in the event when the ctrl key is held down. So this fix to speed can cause a JS error in that case.

comment:3 Changed 5 years ago by nostrademons

If the issue is read-only properties, how about assigning the new custom properties *first* and then setting the new event's prototype afterwards. The new event is just a normal empty JavaScript object, then, so it shouldn't run into any issues with read-only errors on assignment. Then you could set the prototype chain as the last operation in the function, which'll make sure that the returned object returns the original object's values for anything that hasn't been fixed up. It seems like this will work on any browser that conforms to the ECMAScript standard for assignment & prototype access.

comment:4 Changed 5 years ago by brandon

  • Status changed from new to closed
  • Resolution set to fixed

This should be addressed in Rev. [5344].

comment:5 Changed 5 years ago by flesler

  • Milestone changed from 1.2.2 to 1.2.4

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.