Performance ?

[pwnorbitals]

Has any benchmark been done to help users know when using Greenlet is beneficial ? Also, knowing when not to use it would be a great gain.

Anyway, awesome work, thanks !

[developit]

Not yet! I'd like to set up a test page that can be used to demonstrate which types of work are best suited to this technique. It could also be used for workerize.

[jonjaques]

Just out of curiosity, I see you are using Promise.resolve/then so this should work with synchronous functions too?

[hyanmandian]

Yes @jonjaques , look at this example -> https://jsfiddle.net/cd8cnxvg/

[JamesLMilner]

I've been doing some benchmarking of Web Workers and also as an aside greenlet. This is the results I came to when excluding any logic except data transfer for the aysnc function (i.e. just returning the data).

This was run on my Dell XPS,Intel Core i7-4500 CPU @ 1.80GHz, 8GB of RAM, running Xubuntu, code was compiled to ES5 using Webpack 4 in 'production' mode.

n is the number of object keys, who's values are randomly generated from types of boolean, string, number, object and array.

Firefox:

Results explicitly are:

{ "n": 10, "create": 0, "await": 16 }
{ "n": 100, "create": 0, "await": 10 }
{ "n": 1000, "create": 2, "await": 10 }
{ "n": 10000, "create": 2, "await": 24 }
{ "n": 100000, "create": 0, "await": 172 }
{ "n": 1000000, "create": 2, "await": 2678 }

Chrome

{ "n": 10, "create": 1.0999999940395355, "await": 21.000000007916242 }
{ "n": 100, "create": 0.5999999993946403, "await": 6.4999999885912985 }
{ "n": 1000, "create": 0.8000000088941306, "await": 10.10000001406297 }
{ "n": 10000, "create": 0.9999999892897904, "await": 43.30000001937151 }
{ "n": 100000, "create": 0.9000000136438757, "await": 121.79999999352731 }
{ "n": 1000000, "create": 0.9999999892897904, "await": 1415.7000000122935 }

If anyone is interested transferables behave fairly constantly as we might expect (Chrome result):

Some remarks:

• Chrome outperforms Firefox here. For larger inputs this is more noticeable, 2678ms vs 1415ms for 1,000,000 object keys
• Objects with sub 10,000 entries for greenlet are sub ~50ms for transfer to and from the inline worker for Chrome and Firefox
• Increase fairly linear after that point (~150ms for 100,000 vs ~1500ms for 1,000,000)

Hope that is useful to some people (@MagixInTheAir). I am writing a blog post more generally about Web Worker performance which I will leave here once I'm finished up with it.

For transparency, code and demo is here: https://jamesmilneruk.github.io/webworker-perf/

[developit]

@JamesMilnerUK I took a look at the tests. Nice to have this data! I've got an open task to do exhaustive benchmarking of workers that I'll be diving into over the next month or so.

One thing I noticed - right now your benchmark never re-uses Workers (greenlet or manual). It might be good to split out the creation benchmark from the usage benchmark, avoiding any crazy overhead from instantiating 10k Workers (there would be a fair bit).

[JamesLMilner]

@developit, firstly thanks for this great little library, I've really enjoyed using it. Glad to hear the tests were useful :) Feel free to fork anything I've done if it's of use.

Regarding the instantiation of workers, only 1 worker is created per transfer benchmark (i.e. 10 workers are created in total, one for each n value) but this isn't factored into the cost of transfer:

• creation: https://github.com/JamesMilnerUK/webworker-perf/blob/master/src/webworker.bench.js#L59
• transfer: https://github.com/JamesMilnerUK/webworker-perf/blob/master/src/webworker.bench.js#L64)

You can see from the above data creation of a worker is fairly minimal (around 1ms). Having said this I never tested what would happen if you reused a worker for transfer, I'd imagine there might be some marginal performance benefit from doing that (plus you lose the cost of creation).

I wrote up my findings about everything a blog post you can see here: https://www.loxodrome.io/post/web-worker-performance/