New StylesheetProcessor implementation is extremly slow #1872
Comments
|
Hi @skrtheboss, Are you using Windows by any chance? Re-using the worker would definitely be ideal, but in this case it is not possible due to the sync nature of the operations being done. The worker is used to transformer async operations to sync operations. |
@alan-agius4 Anyway, the reason for this is just to synchronously call async code? Seriously? Using child_process / execfileSync is really fancy, tbh 😅, but comes also with huge drawbacks, esp on winsh!t OS. (AFAIK sass runs way faster when called synchronous, but I see the intent. handling all preprocessors different would blow up the code...) cheers |
|
Actually the reason behind this is that both LESS and PostCSS are Async, however the TypeScript compiler is Sync. @flash-me, thanks for the above article, but unless I am missing something that example shared is still asynchronous. To be more precise the line below; |
|
Hi @alan-agius4, Yes I am in deed using windows... But i found a better solution for solving this problem and i have created a pull request. On my machine the performance is way better now: |
|
@skrtheboss, oh wow that's an interesting package. Thanks for sharing let me try it out. |
…n to sync functions #1872 By using sync-rpc ( which is also used by the babel-plugin-postcss package ), we increase the performance over execFileSync calls, which are very expensive.
|
Closed via #1875 |
Sure @alan-agius4, here is an abstract example: function shortAsync() {
return new Promise(resolve =>
setTimeout(() => {
console.log("Short Async");
resolve();
}, 1000)
);
}
function longAsync() {
return new Promise(resolve =>
setTimeout(() => {
console.log("Long Async");
resolve();
}, 5000)
);
}
/**
* This is completely synchronous
*/
const syncRoutine = (function*() {
// Wait 3 seconds, even though its async
yield longAsync().then(() => syncRoutine.next());
// Usually this would be handled faster
yield shortAsync().then(() => syncRoutine.next());
})();
syncRoutine.next();You can return information with cheers |
|
@flash-me, unless I am missing something (which I might cause I am checking from my mob) the above is still async and non blocking, it’s faking sync similar to async/await. This can be tested by doing the below; console.log('before')
syncRoutine.next();
console.log('after')> "before"
> "after"
> "Long Async"
> "Short Async |
That's because you don't have an e.g. here, which is an async context, you would call the first cheers |
|
We don’t know all the file paths beforehand, we only know one file at a time. ng-packagr/src/lib/ts/cache-compiler-host.ts Line 126 in ecc30af |
|
In version 12, we did some changes which should improve the speed even more. This is because in v12 we no longer support Node.JS 10 and thus we can use |
|
This issue has been automatically locked due to inactivity. |
Type of Issue
The new implementation of the
StylesheetProcessorusing workers is extremly slowDescription
I have added a
console.time('StylesheetProcessor')at the beginning of theStylesheetProcessor.processcall and aconsole.timeEnd('StylesheetProcessor')before the css return statement, these are the results:ng-packagr@11.1.4
ng-packagr@11.2.0
I think the problem is, that every time a file must be processed a worker is started, instead of reusing an existing one.
Version Information
The text was updated successfully, but these errors were encountered: