Perf or no perf, there is no try... #1251
Conversation
| } | ||
| } | ||
|
|
||
| _notifyResultSelector(outerValue: T, innerValue: R, outerIndex: number, innerIndex: number) { |
|
👍 |
|
Cool. How do we determine other operators can apply same pattern? try & compare perf manually? |
|
Yes, I'm trying and comparing perf manually |
… ops -> 1.27M ops/sec
…M -> 1.97M ops/sec
…sStopped is honored
|
Merging this work for now, it's about half done, but it gives a lot of examples of how to improve perf by using tryCatch handling that's a little more focused than |
|
Eventually, |
|
I'll try to apply same approach on other operators as well.
: makes sense - in that case if refactoring does not brings noticeable perf improvement, will it still considered as good to checked in by removing usage of custom tryCatcher? |
How about ChakraNode (https://github.com/Microsoft/node)? We may be able to use it as a sample. |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
I discovered today that adding custom tryCatcher members to operators with try/catch optimization concerns actually improved performance quite a bit.
So far:
mapdoubled in overall speed (from factor of 1.7x to 3.2x on my machine),mergeMapimproved by a "factor" of a little more than 1xzipimproved by a "factor" of a little more than 1x-2x.("factor" coming from micro perf output).
This will be part of an effort to go through and examine improvements that can be made where
tryCatch/errorObjectis being used.See commits for details.
All of these perf tests are of course in V8/Node, however I don't see any reason they wouldn't carry over to other JIT'ed runtimes.
cc/ @trxcllnt