Speeding up the JavaScript ecosystem, one library at a time

https://marvinh.dev/blog/speeding-up-javascript-ecosystem/

by fabian2k • 4 years ago

481 188 4 years ago

fabian2k• 4 years ago

My own experience is that JS can be really, really fast if you manage to avoid confusing the JIT. But it's also very easy to make stuff slow and it can be hard to guess what kind of stuff will be an order of magnitude slower because it avoids a fast path.

dottedmag2• 4 years ago

And that's why profiling is the step 1 for any optimization.

maccard6• 4 years ago

Which is why this article is so good IMO.

Yahivin• 4 years ago

In other words: JavaScript is fast, JavaScript developers are slow.

hajile13• 4 years ago

More like JS doesn't do anything to discourage writing slow code. Typescript should have been that tool IMO, but instead, it is so flexible that it doesn't do a thing to help developers understand that they are writing slow code.

croes• 4 years ago

Just because it can be faster doesn't mean it's fast.

maccard6• 4 years ago

No, it's possible to write dodgy code in other languages too - 2 of the examples in this article are in go rather than JS

cxr• 4 years ago

But it's also very easy to make stuff slow and it can be hard to guess what kind of stuff will be an order of magnitude slower

It's not that hard to guess. Just look at what most NPM/Electron programmers and guides recommend you do, and then do the opposite. I.e., think about what your program is doing, and write the most boring, 90s-style code you can. Works really well internally for the Firefox codebase, and has been for 20+ years (for longer than it has even been called "Firefox").

Relevant talk: <https://www.youtube.com/watch?v=p-iiEDtpy6I>

Relevant paper: <https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf>

Relevant thread: <https://news.ycombinator.com/item?id=33790568>

hajile13• 4 years ago

For those who don't want to go through all that, there's basically 3 simple rules to make your code optimizable:

* Objects should have a fixed set of keys (no adding more and especially no `delete`) and the type of the value should never change (note: in JS, a type must NOT be a union of multiple types if you want it to optimize)

* Arrays must be of one type and a fixed length

* Functions must take a fixed number of arguments and the type of those arguments must never change. This is by far the most important if you want to get your function's code optimized.

And as a corollary from this article, it's not JS specific, but converting string -> float and float -> string isn't a cheap operation. I'd go so far as to say that it is the most expensive operation in a huge amount of the functions where it happens. Int to string is especially egregious because it requires a lot of division which is basically the slowest (common) thing you can do on a CPU.

Kamq• 4 years ago

and write the most boring, 90s-style code you can

I think this advice goes way back to before the 90s. I've also heard it called FIAL (Fortran In Any Language).

But, yeah. It's basically always the fastest thing possible in anything even approaching the mainstream.

AtlasBarfed• 4 years ago

"really, really fast"

Compared to what? Polar bears?

Here: is it faster than warm JVM?

winrid3• 4 years ago

V8 is almost never faster than a warm JVM, especially once you get to heap sizes bigger than a couple GB.

You can't even store more than 14m or so keys in a map in Node w/o reaching for an off heap solution due to hard limits in the runtime...

ptrwis• 4 years ago

I would freeze before the JVM would warm up.

mhagemeister6• 4 years ago

Author here.

True, optimize code for JS engines is certainly an art form of its own. What usually works for me is to write boring imperative code when performance is a requirement. That seems to be easily optimizable by current engines.

Also, thanks for sharing my article here on HN. First time for me one of them is on HN.

avh3• 4 years ago

I enjoyed reading your blogpost. Thanks for sharing!

Joeri2• 4 years ago

Or … just don’t use that stuff.

Postcss is not necessary for custom properties. IE isn’t a thing anymore, and using css custom properties directly without a transpilation step is fine. The same thing applies to the for … of issue. Babel is not necessary anymore, all browsers support ES8. JSX is the only thing babel still does that offers real value, but that can be replaced by the runtime alternative developit/htm. We can just stop using babel and sidestep this whole issue.

I see a lot of energy going into making faster build tools, and I feel this energy is misdirected. We need to dramatically strip down the build tools as most of them have become largely redundant since the death of IE.

9dev• 4 years ago

I share your opinion, but recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now. So we’re not fully out of the pit yet, at least until the most valuable company in the world finally cares to fix their fucking browser (yes, dear Apple engineer, I’m talking to you!)

_hyn3• 4 years ago

Apple's app monopoly gets stronger when the browser gets weaker.

CharlesW• 4 years ago

recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now.

Safari is fairly conservative in de-prefixing new features, but also sometimes beats Firefox (e.g. Container Queries and Container Query Units).

For reference, here's the caniuse.com list of Safari CSS features which need prefixing, compared to Firefox: https://caniuse.com/?compare=safari+16.1,firefox+107,ios_saf...

easrng• 4 years ago

It feels kinda weird but a lot of the time you can just use the -webkit- prefixed versions and they'll work in firefox too.

robertoandred• 4 years ago

Prefixes for what?

piskerpan• 4 years ago

I don’t know what you’re using but most developers most likely don’t need “lots of -webkit- prefixes”.

In the link posted by the sibling commenter, I see 2-3 properties that could be useful to the general public. The rest is esoteric, never-ratified, or straight up user hostile (font-smooth)

aphexairlines• 4 years ago

You still need postcss or something like it to use css modules. The alternative of CSS-in-JS requires a build step to extract either a CSS file or inline critical styles for server rendering. The browser-native alternative of CSS Module Scripts doesn't work in Safari.

You still need babel, tsc, or swc to transform typescript to JS.

And then there are imports of files that aren't JS (images, fonts, stylesheets, etc).

Joeri2• 4 years ago

The best approach for a no build CSS approach I've found is using BEM notation to scope the CSS of each component, and then @import'ing the separate CSS files into a master stylesheet. When hosted over HTTP/2 those @imports are downloaded pretty efficiently. However, when doing that the lighthouse score is impacted and it doesn't scale for large websites.

Typescript is indeed a given. There's no good way to do that without build tools. The question is whether typescript's benefits are worth the overhead of the build tooling. I tend to prefer it for libraries with strict API's, but I don't experience as much of a benefit for web applications. I think libraries also benefit a lot from bundling/minifying, so there I would choose a full build tools approach. For small web applications the overhead of the build tooling is not worth the benefit IMHO.

And then when it comes to direct imports of images, fonts, svg, I don't think people should do that at all, even when using heavy build tools. YMMV.

triyambakam• 4 years ago

I recently set up a Three.js app with otherwise vanilla JS using an import map. So refreshing to have zero build step.

minusf• 4 years ago

Installing Tailwind CSS as a PostCSS plugin is the most seamless way to integrate it with build tools like webpack, Rollup, Vite, and Parcel.

zelphirkalt2• 4 years ago

Isn't Babel still needed for metaprogramming, since JS does not have those capabilities itself?

WorldMaker4• 4 years ago

Maybe don't use metaprogramming, then?

The Babel example problem in the article is a fascinating one because that's someone's metaprogramming that's just lost in the ether of time and the labyrinthine tower of a Babel install someone's too afraid to break to just tear down. Not only is it an unnecessary downlevel transform in 2022, but it doesn't look like any of the official transforms that common Babel transforms produced, so who knows what metaprogramming thought might be a good idea that delivers that from that configured stack?

As others have pointed out: JSX transforms have non-Babel options (also including Vite, esbuild, and Typescript).

As for other metaprogramming commonly done in Babel: I would point out that the Stage 0 Decorators that Angular was built on (not to be confused with the Stage 3 Decorators that might actually come to JS) have relied on very specific Typescript build options anyway and the double-up that Angulars tools by default do of also feeding that Babel is kind of silly.

One of those parentheticals also slightly buries the lede that there is a Decorators proposal at Stage 3 and likely to get added to Browsers "in the near future" for those that desperately want to do metaprogramming in JS to have metaprogramming in JS proper, no Babel needed. (There are Stage 1 proposals to offer even more meta- and reflection tools beyond that directly in the language.)

In 2022 though, it is worth asking what in JS needs metaprogramming? A lot of applications get by without it just fine.

nedt• 4 years ago

Funny that you mention htm, because developit is Jason, who build Preact, and the author of the article is Marvin, also working on Preact. So I'm pretty sure the author know about what is needed and the alternatives and still sees use cases and just wants faster builds. Just look at the article before about unit tests in 1s. That's where he is coming from.

meet_zaveri• 4 years ago

I see a lot of energy going into making faster build tools, and I feel this energy is misdirected. We need to dramatically strip down the build tools as most of them have become largely redundant since the death of IE.

what if we standardize browsers ? Like if it happens, we get easily all of the power from browser itself. It's same story like ES6 and later versions did to underscore and lodash (long live lodash).

This will make all build tools OBSOLETE

cogman103• 4 years ago

Heh, so many of these fixes boil down to "I'm converting this thing to a string and then searching the string". And, funnily, I've often stumbled on this problem with Java programmers. They'll take a nice rich type, turn it into a string and then spend a bunch of code/time turning that string back into something else.

Super wasteful when you start thinking about what all that means. Rather then having a representation that neatly fits into registers, now you have this blob of memory that has to be linearly searched to pull information from it. Just. yuck.

And why do devs do this? TBH, I really don't know. Because regexes are easier to understand? IDK.

Waterluvian4• 4 years ago

I’ve never seen this approach. I imagine I’m just not working in a domain that touches on problems “solved” this way. Any popular examples to point to?

cogman103• 4 years ago

Nope, just stories from my day job.

One time, to solve the problem of "we want floating point numbers that are close to be considered equal" on an object, the programmer decided to take every field of that object (reflectively of course) turn that into a string, and then compare the two strings together.

Another time, in order to convert a LocalDate to our own internal date representation, a dev decided to toString the local date, split on the `-`s to extract the day month year. (Yes, localdate has day, month, year methods).

One time, to convert an int to a double a dev decided to turn that int into a string and then used "Double.parseDouble" to turn that int into a double (I wish I were joking).

All these and more were found through the joys of profiling :D

_aavaa_2• 4 years ago

I have, and it boggles the mind. You'd think Java was a string-oriented language.

Dachande663• 4 years ago

Common example I’ve seen is checking if an IP is in a range. Most (JS) libs I’ve seen do something like regex or, more commonly, split on periods and then have a set of nested ifs. Versus if you have a proper IP type, you check if its long value is between ranges. (Not saying you can’t do this, but because so many times an IP is stored as its string representation, that seems to be the default.

usrusr• 4 years ago

Also haven't seen it, but I could imagine it happening if someone desperately misses duck-typing due to too many similar classes not under their control (can't make them share interfaces) and they have a lot of routine with e.g. json from/to but none with reflection. (I do enjoy a hearty dose of tojson in my println debugging)

rr888• 4 years ago

Another common one is converting booleans to "Y" and "N".

karmelapple• 4 years ago

We saw it with contractor-developed code. They took JSON from an API, then converted it to a big blob of text, and did some gnarly searching.

It made no sense.

But we were also in a rush to get this app built, so we didn’t push back on this tortured logic. But we were saddled with this technical debt for an embarrassingly long time.

ErikCorry• 4 years ago

People will convert a float to an integer by using parseInt. That function automatically converts its argument to a string, then parses it as an int, ignoring anything after the decimal point.

Completely fails for a number big enough to be stringified to 1.34e20.

Plot twist, if your number is in a reasonable range this is very fast because there was one a popularJS benchmark that did this.

mcculley• 4 years ago

I have had to do it where all of the member methods are private (or otherwise inaccessible to me) and toString() is the only useful way to get information out of the object.

jiggywiggy• 4 years ago

Most of these actually come down to supporting logic in comments to turn thing on / off, etc. Or enhancing parsing. Not as much what you describe.

notatoad2• 4 years ago

And why do devs do this? TBH, I really don't know.

it's one of the pillars of the unix philosophy at work - text is the universal interface.

your nice rich type requires figuring out how that type works, maybe even reading documentation. if you make it a string, you can just treat it like a string. and we all know how to handle strings, or at least how to copy code from somewhere else that handles strings.

Someone1234• 4 years ago

C#'s System.Object base type contains a ToString, allowing any richer object to fallback into such inefficient systems if required.

I'd also caution that "everything is a string so no need to read the documentation" is unrealistic and even outright dangerous. *NIX's string philosophy has directly resulted in multiple security vulnerabilities.

LudwigNagasena• 4 years ago

It’s not even text. It’s just UTF-8 at best and just ASCII in some cases. When did awk get Unicode support? 3 months ago?

rk062• 4 years ago

One thing is that there is no deep comparison for objects. Say if you want an object as a key in Map, how would you go?

In c#, I would use a Tuple. Or override equals to do a deep check.

avmich• 4 years ago

Can you write deep comparison? For a particular object? Or for many objects representable as a JSON, use a generic JSON comparison?

shakow• 4 years ago

My Java is a bit rusty, but can't you define the hashing function for this class?

WorldMaker4• 4 years ago

In JS there are a pair of Stage 1 proposals to increase support for richer/more complex keys in collections like Map: https://github.com/tc39/proposal-richer-keys

Strings seem really easy for composite keys and "deep comparison" for objects, but you could do more like C# actually does under the hood which is compute simple hash numbers (getting back to the article's point that computers are often faster with number calculations than string work).

C# does most of its equality "magic" with GetHashCode() (surprisingly not Equals() and obviously not ToString()). (Relatedly this is why C# linters will yell at you if you override Equals but not also GetHashCode. Equals seems the more "useful" override but GetHashCode is the actual work horse.) Most implementations of GetHashCode (even for deep comparison situations) are generally starting with some random prime constant XOR bits of all the data and return the integer you have left after all the XORs. You can do the same thing in JS today if you wish. Modern .NET now has a nice System.HashCode helper class for doing it quickly with a lot of good best practices baked in (a strong starting constant, for instance), so it's easy to forget the bad old days of writing all those XORs by hand, and .NET has always had GetHashCode a required method of System.Object so "recursion" of hashcodes is guaranteed to be simple. But those things aside, it's still really easy to compute hash codes by hand in JS to use for comparisons than to use string manipulation, if you put your mind to it.

esperent2• 4 years ago

regexes are easier to understand

Not a statement I ever expected to see.

rising-sky• 4 years ago

Same, I mean they are tricky to get a handle of but seemingly logical once you gain familiarity, until you have a use case that does not fit into a previously encountered pattern, and then it's back to the drawing board. But I guess, it's easier then reading the manual but what do I know

jbverschoor• 4 years ago

Why? Because it’s all they know.

EMM_386• 4 years ago

Java has (had?) such beauties as "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStates".

Now imagine a bit of reflection on that to do some string manipulation.

Good times!

pjmlp• 4 years ago

Smalltalk, Objective-C and Swift top that, because the parameter names are part of the method name as well.

pjc502• 4 years ago

They'll take a nice rich type, turn it into a string and then spend a bunch of code/time turning that string back into something else.

They find the strongly typed system "inflexible", so they fall back to a "stringly typed" one.

hombre_fatal• 4 years ago

I think it’s just because everyone knows how to work with strings, it’s so tangible, and you can see what data a string contains right there in the print(thing).

You don’t even have to know what the type is of the thing to work on it’s string representation.

maccard6• 4 years ago

I'm guilty of having written code like this on occasion, as I'm sure we all are. It's easy to look at these changes and say "of course it's slow", but for every instance of this that OP fixed there's probably 99 other occurances of the same thing that _don't_ matter for performance. In a perfect world, sure, everyone would know whether they're on the hot path or the slow path and prioritise accordingly - it doesn't matter if something that is called once a day takes 15ms instead of 0.15ms, until someone adds it to the hot path and it gets called 290 times.

josephg• 4 years ago

I stubbornly hate code like this - but largely because of the security and correctness nightmare this is when combined with user generated data.

For example, in a library one of my coworkers wrote, object paths were flattened into strings (eg “user.address.city) and then regular expressions and things worked on that. Sometimes user data ended up in the path (eg “cookies.<uuid>”). But then - what happens if the user puts a dot in their cookie? Or a newline? Does the program crash? Are there security implications we aren’t seeing? What do we do if dots are meaningful? Do we filter them out? Error? Escape them (and add a flurry of unit tests?) Are there bugs in the regex if a path segment is an empty string?

It’s a nightmare. Much better to have paths be a list of keys (eg [“cookies”, uuid]). That’s what they represent anyway, and the code will be faster, and this whole class of string parsing bugs disappears.

pfych• 4 years ago

It's crazy that their patch in Semver (something that doesn't really affect the final build) saved them 4.7s in their build! I never would have thought a package like that would have such an affect on build time.

mhagemeister6• 4 years ago

Author here.

Yeah, that was surprising to me too. You always discover something you would have never thought of on your own. It's what makes profiling such an enjoyable task for me!

flanbiscuit• 4 years ago

I'm curious to see the project that you tested this against. To me it seems like you either tested this against a rather large existing code-base you work with or you code-generated something pretty huge as I've never seen such slow build times. If possible, could you put it up on github or gitlab?

romellem2• 4 years ago

Very interesting, and great work contributing to the open source community!

Can you elaborate on how you did the profiling to identify the (potentially) slow parts?

llanowarelves• 4 years ago

Yes this would be helpful.

JavaScript programmers, in my experience, don't really use profilers like "traditional" programmers do.

Maybe it's as much the tooling as it is the culture?

chii• 4 years ago

The profiler in chrome is pretty good, and can be used fairly easily for both frontend and backend profiling.

If said programmer doesn't use it, it's because they lack engineering maturity and competency.

mhagemeister6• 4 years ago

Author here.

I mainly used node's `--cpu-prof` flag to generate a profile. Tried loading the trace into Chrome DevTools at first, but wasn't able to load the file supposedly because they are too big. So I used https://www.speedscope.app/ instead and which loaded them without any issues and is very snappy overall. What's more is that it allows you to display a left-heavy flamegraph which makes it much easier to spot functions taking up a lot of time. Speedscope is an amazing tool!

For webpack based projects the traces were missing quite a bit of data and I had more luck with their own profiling plugin: https://webpack.js.org/plugins/profiling-plugin/

semiquaver• 4 years ago

Speedscope is the best.

romellem2• 4 years ago

Awesome, thanks! I too have found Chrome's profiler lacking, so will definitely have to check out https://www.speedscope.app/.

seydor2• 4 years ago

Don't speed it up,just remove it. I just logged into AdWords after a long time, and OMG the page is 178MB of javascript and a clunky hell that surely turns a lot of computers to space heaters. This madness has to stop

o_m• 4 years ago

With that logic just stop using AdWords. It bloats the web.

Javascript isn't going away tomorrow, even if a replacement was released tomorrow it would take years for all the web to move.

seydor2• 4 years ago

I will, i set an end date for the campaign and don't plan to use it ever again until i am forced to (and maybe alcohol will help)

I'not arguing to remove javascript altogether, just to stop this bloat

jongjong4• 4 years ago

> 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).

srcreigh• 4 years ago

The article describes significant time savings from these changes.

jongjong4• 4 years ago

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.

samus4• 4 years ago

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.

tonto2• 4 years ago

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

jdmichal• 4 years ago

    // Does the same as `Number.prototype.toFixed` but without casting
    // the return value to a string.
    function toFixed(num, precision) {
        const pow = 10 ** precision;
        return Math.round(num * pow) / pow;
    }

I know doubles are big, but doesn't this combination of multiply-and-divide introduce the possibility of precision issues that I'm assuming is not applicable to `toFixed`?

Unless I'm wrong, I would be very hesitant to use this version of the method when I don't control the input.

aeyes• 4 years ago

This is processing numbers which appear in SVG files which are basically coordinates, they aren't that big.

chrismorgan4• 4 years ago

This need not be true: you can put objects and viewboxes wherever you like in SVG. <svg viewBox="1234567890 1234567890 100 100"> is perfectly valid.

Many years ago (Adobe SVG Viewer days) my Dad generated SVG files from geo/map data and at first used the original coordinates or something, but float error made it untenable—some viewers would end up quantising some things (e.g. the shape, the viewbox, individual nodes, even once you applied a transform or SMIL animation to them, the hover hitboxes—I don’t remember the particular details, but it was a few things) so they’d end up off by as much as hundreds of pixels in the most extreme projections. Therefore he ended up rezeroing to work around this, transforming into a more friendly space before producing the file.

In the context of SVGO: really, the whole decimal places thing is stupidly bad, because decimal places can be of wildly differing importance in different contexts, and it wouldn’t be that hard to figure most of them out. In some situations a third decimal place will be more valuable than another number’s hundreds place. And SVGO’s approach is particularly bad because it treats each number individually, not attempting to compensate for the error it introduces, and so the presence of fine detail can easily completely destroy things due to untreated cumulative error.

jansan4• 4 years ago

There certainly are issues with precision:

    toFixed(1000.005, 2); // returns 1000.01
    toFixed(1.005, 2)     // returns 1

Rounding to a fixed number of fraction decimals is extremely tricky, much trickier than it appears on first view.

This is beaten to death at Stackoverflow, but I can tell you that almost all (or all?) of the solutions provided don't work for all cases:

https://stackoverflow.com/questions/11832914/how-to-round-to...

maccard6• 4 years ago

This is an argument for having these fundamentals implemented in the language's standard library IMO.

Valter42• 4 years ago

This toFixed is if the precision is below 16, JS just doesn't work with more, you literally can't have more than 16 digits after the decimal, JS will round it (very poorly btw)

BTW if one needs to round to more than 16 you can use toLocaleString and pass minimum and maximum fraction digits which has a limit of 20. Ain't much but you could not expect more from JS :D

ayhack• 4 years ago

Speed on roblox

randompi• 4 years ago

Whats that profiler being used?

hajile13• 4 years ago

Looks like the one built into chrome. You can open your browser and attach a node instance so you can debug and profile it.

Here's a basic How-to:

* Run node with `node --inspect <file>`

* Open Chrome and go to `chrome://inspect`

* After it finds your target, click the inspect button to launch a debugger.

alangpierce• 4 years ago

It looks to me like the profile viewer is actually speedscope ( https://www.speedscope.app/ ). I find it nicer for exploring profiles compared with Chrome's built-in viewer.

To use with Node.js profiling, do the `node --inspect` and `chrome://inspect` steps, then save the profile as a .cpuprofile file and drag that file into speedscope.

Another thing I've found useful is programmatically starting/stopping the profiler using `console.profile()` and `console.profileEnd()`.

mhagemeister6• 4 years ago

Author here.

Answered this elsewhere here: It's the `--cpu-prof` argument with node and the resulting profile is loaded into speedscope.

hajile13• 4 years ago

Sucrase is faster than SWC and esbuild in single-threaded performance and something like 20x faster than babel.

https://github.com/alangpierce/sucrase

The real issue isn't JS, but is the lack of profiling (as shown here) combined with wanting to be everything to everyone leading to layers of bloated abstraction.

pohl• 4 years ago

Any idea how well does Sucrase compare when multiple threads are allowed?

hajile13• 4 years ago

You can run multiple processes of Sucrase if you want at which point it will still be faster than threaded SWC/esbuild. This is currently up to the user, but hopefully, the authors follow through on this issue and integrate an easier way for users to do this (though I don't know if they want that as core functionality).

https://github.com/alangpierce/sucrase/issues/730

JS JIT creators don't get enough credit for their string implementations. Not much comes close when you consider both performance and robustness they packed into the C++ implementations that JS is actually using.

chrismorgan4• 4 years ago

The real issue isn't JS

Yet it should be acknowledged that JS encourages various inefficient patterns.

Comparing with Rust, with which I am very familiar, I think that you’d be less likely to have most of the problems (some a little less, some a lot less):

• isBlockIgnored: it might still be tempting to do it the /…/.test(rule.toString()) way, but you’d be less likely to do it that way for two reasons: working with the actual AST is a good deal more pleasant than it is in JavaScript (due to a better type system, pattern matching and iteration tools), and you have to go a little further out of your way to use regular expressions since they’re not just built into the language.

• strongRound: somewhat less likely, because its inefficiency is more obvious, and because the developer is less likely to even find format!("{:.1$}", data[i], precision).parse().unwrap() than +data[i].toFixed(precision).

• stringifyNumber: similar remarks on regular expressions, you’re more likely to manipulate the strings rather than bothering with regular expressions (because they are a bother, even if minor, unlike in JavaScript).

• monkeys: well, in this case the issue is JS; the whole thing would be a non-issue in Rust.

• _loop: again JS problems and a misapplication of old-JS/new-JS–mixing techniques.

• semver: in good design this would be somewhat less likely in Rust because it’s likely to shift the parsing invocations to the caller in a way that makes the inefficiency a little more likely to be noticed, but in practice this would probably be about as likely to happen in Rust as in JavaScript.

And these are fairly tame cases, all things considered. Simplifying a bit, JavaScript makes it easy to do very inefficient things by accident, but Rust helps in many (though certainly far from all) cases, making it so that some of those can be optimised so that they aren’t inefficient after all, some simply don’t compile or can’t be expressed in the first place, and some must be expressed in slightly different ways that make the inefficiency more likely to be noticed and avoided.

—⁂—

You also should really specify that Sucrase achieves its speed by doing something completely different. SWC and esbuild are explicitly doing basically what Babel does, and so comparisons between them and Babel are meaningful, but comparisons with Sucrase cannot be used to vindicate JavaScript performance. Ports of what the likes of Sucrase or Bublé do to Rust or even Go would blow the corresponding JavaScript library out of the water.

wonnage• 4 years ago

One slightly annoying thing about esbuild/swc is that they're faster by literally not being equivalent to Babel. esbuild intentionally does not emit ASTs, and SWC has their own flavor that is not compatible with Babel. Furthermore, both are written in non-JS languages, meaning any sort of plugin system either has to be written in Go/Rust respectively, or suffer massive performance hits from crossing the JS runtime boundary. SWC abandoned plugins in JS for this reason.

The dirty secret is, as Sucrase (https://github.com/alangpierce/sucrase) reveals, just that Babel is slow and the codebase really pays homage to the project name. Simply computing the config for transforms takes dozens of milliseconds on my machine as it does a bunch of filesystem reads.

So esbuild/swc etc. aren't gaining some magical compiled language speedup, they're just... not doing the dumb things that Babel is. Not ragging on Babel here, it's a 7 year old project originally written by a guy fresh out of high school. I bet a ground up rewrite of Babel could accomplish the same.

greggman3• 4 years ago

good stuff but something was mis-transcribed. This line can't possibly work

     for (const i = data.length; i-- > 0; ) {

chrismorgan4• 4 years ago

The original used var for both i and rounded. let would work here.

mhagemeister6• 4 years ago

Author here.

Whoops, good catch! That's definitely an error on my part. The original code uses `var` there. Thanks for pointing it out.

cjblomqvist• 4 years ago

It's it just me or why isn't the total build time and percentage presented? Without that the time savings seems relatively irrelevant?

hajile13• 4 years ago

Relative percentages would be nice for more context, but saving ~12.5 seconds waiting on my build is significant enough that even if it were a small percentage of total time, it would still be well-worth doing.

I think the real point here is that more profiling could give some great results without tons of work.

HiJon89• 4 years ago

Thanks for the great writeup and the great work!

The fact that half the comments here are dismissive or condescending is such a sad indictment of HN culture :(

mhagemeister6• 4 years ago

Author here.

Thanks for the kind words!

mschuster91• 4 years ago

The old trap of tech debt. Basically... back when these tooling projects started, stuff like casting stuff around all the time, using un-optimized tree algorithms, inefficient value objects or whatever didn't matter - because the projects that were built using them were so small the inefficiencies didn't matter. And once the projects got bigger, inefficiencies weren't really looked at for three reasons: the obvious "if the source gets larger, the build time goes up as well", because people simply got more powerful hardware - and finally:

Because most JS developers simply aren't your old guard neckbeard coders with decades of experience under their belt. They're fresh coding academy graduates that don't teach stuff like flame graphs or performance tracing in general, and simply are used to stuff taking a lot of time. And fwiw, knowledge of optimization techniques isn't really widespread even in senior developers. Modern computers are simply "fast enough" for many people (and especially corporate beancounters) to not care.

hajile13• 4 years ago

There's another issue at play here.

Nobody makes money from making SVGO faster.

Your customers don't run SVGO and only care about the performance of the output. Devs care, but not enough to do anything about it. Companies care about dev productivity, but the cost of the hours to run through the profiler isn't something they are willing to pay for.

And finally, there aren't enough maintainers/contributors to these projects. The core team is some volunteers. When they have spare time for the project, it's almost always going to be used to keep up with web standards, add missing features, or chase down bugs that impact the final output. They know performance matters, but thers's always something more important to do instead.

bouk3• 4 years ago

One of the best bang for your buck optimizations I did recently was add the following to our next.config.js (we're using V13):

  const swcOptions = require('next/dist/build/swc/options')
  const { getLoaderSWCOptions } = swcOptions
  swcOptions.getLoaderSWCOptions = function (...args) {
    const result = getLoaderSWCOptions(...args)
    result.jsc.target = 'es2022'
    return result
  }

This overrides the target https://swc.rs/ uses from the default of es5 to es2022, which sped up our quite heavy app by up to 3X in hot code paths, just by using newer JS syntax instead of falling back to 'transpiled' versions. Unfortunately Next.JS doesn't allow setting the target directly. My hunch is that especially this syntax in our hot path was a big benefactor:

  function cloneAndSetProperty(obj, prop, value) {
    return { ...obj, [prop]: value }
  }

chrismorgan4• 4 years ago

On your cloneAndSetProperty, consider if you can use a prototype instead of a clone:

  function chainedPrototypePlusProperty(obj, prop, value) {
    const newObject = Object.create(obj);
    newObject[prop] = value;
    return newObject;
    // Alternatively: return Object.create(obj, { [prop]: { configurable: true, enumerable: true, value } });
  }

It depends entirely on what you’re doing with it (not mutating obj while you keep the returned object, not depending on properties being own), but in some cases this will be suitable, and depending on the data and what you’re doing, could be drastically faster (it’s O(1) rather than O(n) on the number of properties, and access after could be much of a muchness).

bouk3• 4 years ago

I've tried this and found it to be much slower

danfritz• 4 years ago

You can enable the experimental `browsersListForSwc: true,` option which uses your browserlist to determine the appropriate target. You can also disable `legacyBrowsers`

ref: https://nextjs.org/blog/next-12-2#other-improvements

bouk3• 4 years ago

Nice, it seems this is now the default in Next v13, just updated! (We were actually using v12.0 still)

tonto2• 4 years ago

reminds me of a bug bounty type post :) would be nice to get awarded similarly

newbieuser• 4 years ago

Most javascript packages come with a memory leak as well as ease of use. and as the number of packets increases, unfortunately the memory leak increases exponentially.

v0idzer0• 4 years ago

Really fascinating read. Thanks for sharing.

jgalt212• 4 years ago

If you're serving SVG over gzip or similar, you'd be hard-pressed to sell me on the value of SVG optimization.

I'm also not keen on javascript minimization. Most of the delay on the client in not in the transport, but in the parsing. For this reason, I do think tree-shaking has good value.

Speeding up the JavaScript ecosystem, one library at a time

Related Stories