chore: make jsii fully synchronous
#3467
Conversation
With a sample set of 1, I have detemined that there is about 30% tax caused by asynchronous functions in the compiler. The `typescript` compiler itself is fully synchronous, and we basically moved to do the same, and this turns out reducing the amount of time wasted in the runloop and in promise bookeeping. Tested on `aws-cdk-lib`, it turns out to be reducing the compile time from ~142 seconds to ~100 seconds.
RomainMuller
force-pushed
the
rmuller/performance-audit
branch
from
39bcb7e
to
2cb1c0d
Compare
|
That seems like an inordinate % of time spent just in promise/callback/event loop management. I wonder if the TS compiler being fully synchronous is for performance or design reasons. Even their fs calls when writing .d.ts and .js file output are sync? Either way it's quite interesting. I'd be curious to run comparisons across more libraries and different hardware configurations with some flamegraphs for a clearer picture of the difference. |
I reckon the TS maintainers wanted to turn the compiler async but it turned out to be a humongous task. I think the TS compiler itself spends enough time doing I/O that using async will yield performance improvements, whereas the But all in all I agree this magnitude of a difference looks pretty surprising. I expected some, but not that much... It could be just the particular case I used magnifies that (the measurement protocol isn't very scientific here)... |
RomainMuller
force-pushed
the
rmuller/performance-audit
branch
from
500732a
to
e3b953f
Compare
RomainMuller
force-pushed
the
rmuller/performance-audit
branch
from
e3b953f
to
adb5af6
Compare
| @@ -186,7 +184,7 @@ export class Compiler implements Emitter { | |||
| return watch; | |||
| } | |||
| // In blocking mode, returns a never-resolving promise. | |||
There was a problem hiding this comment.
May be this is comment not relevant anymore
|
Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it! |
|
Merging (with squash)... |
In aws#3467 the comiler was made fully synchronous which also removed a never resolving promise used by --watch. When the compile is run in watch mode, the watcher is started in the background and control is returned back with watcher. For the compiler watcher to keep running the control should not be yeilded back to the caller
While making the compiler fully synchronous (in #3467) a un-resolveable promise was removed which is used by `--watch`. When using watch mode, the typescript compiler creates a watcher, and hands back the control to the caller of watch, to allow caller to control the watcher instance. Since JSII does not do anything with the returned control, we need to return an un-resolveable promise which will keep the watcher running for ever (or till the whole program is killed) --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
With a sample set of 1, I have detemined that there is about 30% tax
caused by asynchronous functions in the compiler. The
typescriptcompiler itself is fully synchronous, and we basically moved to do the
same, and this turns out reducing the amount of time wasted in the
runloop and in promise bookeeping.
Tested on
aws-cdk-lib, it turns out to be reducing the compile timefrom ~142 seconds to ~100 seconds.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.