>> Most popular libraries can be sped up by avoiding unnecessary type conversions or by avoiding creating functions inside functions.
I stopped reading there. This performance overhead is insignificant. The way to speed up libraries is to keep time complexity low; e.g. don't search through every item O(n) when you could just have done a constant time lookup O(1)... Or don't have nested for loops with O(n^2) complexity when the problem could have been solved with two non-nested loops in O(n) time (e.g. using a Set or Object for lookup).
All the issues mentioned are related to the usage of shitty frameworks and build tools. The problem is not caused by a single regex; the real issue is likely that a regex is being created too many times in a loop instead of being created once and re-used. Related to neglected time complexity.
> Config parsing as a whole takes 4.3 seconds
WTF! If parsing a config file takes more than 20 milliseconds, you've got some serious issues with your project... There is no excuse. Even if your project is highly complex and feature-rich, you can just break it up into smaller sub-projects.
This article doesn't give any useful info because the project it's analyzing is just so bad.
It's like watching a turtle complete a 100-meter race and then taking away the lesson that crawling on one's stomach isn't a great strategy for a human to win the 100-meter race at the Olympics. Duh!
The whole project is a giant flaming pile of garbage. There is no interesting lesson to learn from it. Functions named 'monkeys' or 'perItem' or 'strongRound'?... Class named 'ConditionalRuleset' (WTF is a conditional ruleset, why would any project need it??? This abstraction makes no sense). What about 'isBlockIgnored(ruleOrDeclaration)'? Sounds like unnecessary complexity bloat when devs keep inventing new abstractions to give themselves more billable hours of work.
I would jump dump all these bloated libraries and frameworks and start the project from scratch.
your comment is sort of selfish because you don't seem to understand a good portion of the JS ecosystem is based on top of the libraries the author has touched. welcome to the real world
I know much of the JS ecosystem sucks. Don't blame me for industry leaders brainwashing and coercing us into using these horrible frameworks and libraries... And then making it into a mono-culture which shuns all alternatives.
You don't have to use them; you can find a different job at a smaller company. There are still companies doing it right and there are still good, lightweight tools out there; they're just hard to find.
Over 3 seconds for booting up is fine, heck, sometimes a few minutes is OK, but just to parse the config file? No way. If it takes that long to parse, it's not even a config file; it's a monster. I bet it has many other problems beyond performance.
That's true to an extent. Many important optimizations will be performed by the JIT compiler, but only as long as the programmer doesn't make it hard to do so! The JIT compiler has to meet a strict compromise to meet between itr execution time and the performance of the code it generates. Type inference (to optimize object accesses), escape analysis (to move allocations from heap to the stack and to optimize away closures), and other expensive interprocedural analyses are often not executed since the user might navigate to another website before they have paid off.
any tools to help analyze this type of thing (e.g. what is and is not optimal for the jit)? have heard the term deopt but not sure how to get visibility into that
The JVM can be instructed to emit diagnostics regarding JIT compilation. Dunno if similar things are possible with JavaScript engines. Apart from that, profiling. Coding style is being discussed to death in other comment threads here. In short, "boring code" (few closures and functional idioms, no reflection, careful use of dictionaries, no ultra-flexible function parameter lists, avoid regex unless absolutely required) avoids surprising (read: hard to optimize) behavior.
But maybe all of this is besides the point. It's unrealistic to do heavy duty processing in a dynamic language and expect that the JIT always saves us. In comparison, Python programmers suffer no illusions that their code is usually just "fast enough", and call out to external libraries when heavy duty processing is required. Modern browsers provide some of these optimized capabilities for JavaScript, and they should be used whenever possible.
I stopped reading there. This performance overhead is insignificant. The way to speed up libraries is to keep time complexity low; e.g. don't search through every item O(n) when you could just have done a constant time lookup O(1)... Or don't have nested for loops with O(n^2) complexity when the problem could have been solved with two non-nested loops in O(n) time (e.g. using a Set or Object for lookup).