Question

I am building a library which augments the standard JS input events.

This means firing off a great many events for multiple touches at input sampling rate (60Hz) in the browsers of ARM devices.

I have looked at this jsperf and it produces about 250,000 ops/sec on my 1.7Ghz Sandy Bridge i5 and I will test my iPhone5 and Nexus7 on there shortly.

My question is will an unlistened-to event be processed quickly?

Also is there a way to skip processing for generating an event if I know the event is not being listened to?

Answer 1

I think that jsperf muddies the waters when it comes to dispatching and handling events because event listeners are also added and removed every test loop iteration. It sounds like your use-cases have high-frequencies of dispatching and handling events, but comparatively low demands for adding and removing event handlers.

I put together a jsperf that focuses on wrapping a native event with a custom event and then disatches the custom event. The test scenarios are based on:

• Presence or absence of a listener for the custom event
• Immediate vs lazy initialization of data associated with the custom event
• The impact of the above factors when dealig with “light” vs “heavy” intitialization demands

To test the “heavy” vs “light” initialization demands, each custom event creates an array of either 10 or 1000 random numbers.

Regarding lazy initialization of custom event data:

• When a listener was present, the lazily init’d event was usually a bit slower. For “light” data it was sometimes as low as 0.8x the speed of the immediately init’d event.
• Without a listener, the lazily init’d data was usually faster for both “light” and “heavy” data. For “heavy” data, it was generally 2x-10x faster.

My question is will an unlistened-to event be processed quickly?

In everything I’ve seen, an unlistened to event is always processed faster than an event that has an associated handler. But, I think this will only have a large impact if the event handlers, themselves, are rather slow and costly. Also, the higher the cost of creating the custom event the less this will matter if the custom event is created either way.

Also is there a way to skip processing for generating an event if I know the event is not being listened to?

Two things come to mind:

• Expose the knowledge of whether the event is being listened to or not to the process that generates and dispatches the event, and then have that process skip creating the event if it knows nothing is listening.

• Sounds like the code that generates the custom event will, at some point or another, listen for a native event and then create a custom event(s) based on the native event. In this scenario, you could ignore the native event until an event listener for your custom event has been added, and then ignore the native event again when all listeners for the custom event have been removed.