constexpr

5 ms·

1.
by constexpr 3y ago
That's the only image with a non-zero EXIF orientation. Which probably means you're using an older browser (e.g. Chrome started respecting EXIF orientation in version 81+, which I think came out 3 years ago?). You'd have to u
2.
by constexpr 3y ago
Hello! I made this. People are talking about not wanting pictures to be initially blurry before they finish loading. I understand that too, and I'm not sure how I feel about it myself (I could go either way). But for what it's wor
3.
by constexpr 4y ago
There are two performance implications of "modularization": initialization-time and run-time. You are correct that initializing many modules is usually slower than initializing one module [1]. However, bundling puts all modules in
4.
by constexpr 4y ago
Carto was a blast and really well made. Loved the humor and world building, and the puzzles were satisfying.
5.
by constexpr 4y ago
I came across one of these once without knowing about the phenomenon. It’s in Golden Gate Park near the intersection of JFK Drive and Transverse Drive. Water in the stream next to the road appears to flow uphill. Very surreal.
6.
by constexpr 5y ago
No, I haven't experimented with generics and esbuild. I hadn't considered whether generics could improve performance or not. Just thinking about it quickly now. I'm not convinced it would because esbuild hardly makes use of i
7.
by constexpr 5y ago
That comment wasn't about Go exclusively. My point was that porting single-threaded code to a native language doesn't necessarily cause huge order-of-magnitude speed gains, especially if you plan on sticking close to the original
8.
by constexpr 5y ago
Yes that allows for shared memory. But the TypeScript compiler is written in TypeScript, and you can't put JavaScript objects (such as the TypeScript AST) in a SharedArrayBuffer. So you'd have to port the TypeScript compiler to an
9.
by constexpr 5y ago
Yeah I was afraid of that. Ideally it would be possible to do type checking in parallel at the function level or something, but TypeScript allows you to omit the return type and then infers the return type from the function body which adds
10.
by constexpr 5y ago
The problem is that you can't use shared-memory parallelism in TypeScript. If you could, then the most straightforward way of speeding up the TypeScript compiler would be to parallelize the compiler, not to port it.
11.
by constexpr 5y ago
I'm the author of esbuild. I think this is a very smart, practical choice and is one of the approaches that has the best chance of succeeding (the other being a semi-automated porting tool instead of a purely manual port). I'm ver
12.
by constexpr 5y ago
I'm the author of esbuild. I hadn't written Go before I started esbuild and I thought I would miss generics more, but I didn't. There is literally only one situation in the whole esbuild code base where I've found myself
13.
by constexpr 6y ago
It is also all custom: https://github.com/esbuild/esbuild.github.io . YAML files that get converted to plain static HTML pages. It's designed to work well without any JavaScript. Even the animated graphs on the hom
14.
by constexpr 6y ago
I'm the author of esbuild. Rest assured that I am very interested in supporting it and am actively working on it. It's just unfortunately very complicated to correctly, especially without affecting any of the other existing featur
15.
by constexpr 6y ago
Both would be good to file. I’m happy to investigate myself if you don’t have the time. One thing to be aware of is that some other tools that integrate esbuild do so incorrectly. For example, the 3rd-party integration of esbuild into Webpa
16.
by constexpr 6y ago
Ah I see, no worries. I assumed you were trying to compare against a production build since that's what "parcel build" does.
17.
by constexpr 6y ago
I noticed you changed this to "dev" instead of "production". Just letting you know that this will select the development build of React instead of the production build, which is not optimized for size and will lead to a
18.
by constexpr 6y ago
It would be great if you could file these as bugs against esbuild! Sounds like these should be easy to fix.
19.
by constexpr 6y ago
It's strange that they are comparing output size without passing --minify to esbuild. Why compare the size of the debuggable output? And if you care about output size, you would also need to pass --define:process.env.NODE_ENV=\"pr
20.
by constexpr 6y ago
I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602 . Microsoft's TypeScript team has a lot of priorities and
21.
by constexpr 6y ago
A new JavaScript/TypeScript bundler written in Go that's 10-100x faster than Webpack, Rollup, and Parcel: https://github.com/evanw/esbuild
22.
by constexpr 6y ago
Shaking up the JavaScript build tool ecosystem with https://github.com/evanw/esbuild , a bundler and minifier that's 10x-100x faster than industry-standard ones (Webpack/Rollup/Parcel).
23.
by constexpr 7y ago
I'm not sure that this is a CPU bound workload. You're right that if this is CPU bound, LLVM's code generation should come out on top, even if only slightly, but that's not the case. Perhaps writing a JavaScript bundler
24.
by constexpr 7y ago
Yeah benchmarks are tricky. I'd rather not tweak the parameters for Rollup in this case because then it wouldn't be a fair comparison. Rollup would then be cheating because it has to do less work. It could definitely be useful to
25.
by constexpr 7y ago
Both the Rust and Go parsers were written by hand. They are also very similar (basically the Go version was a direct port of the Rust version) so the performance should be very comparable. I assume by zero-copy you mean that identifiers in
26.
by constexpr 7y ago
Thanks! Will do. No wonder the three.js repo takes so long to download :) You probably aren't seeing the AST optimizations because they are actually in the parser. Search for "mangleSyntax" to find the optimization code. This
27.
by constexpr 7y ago
> If you're doing arena allocation in a compiler you might as well just leak all your allocations (which you could get with bumpalo with a 'static lifetime); then you won't have to deal with lifetimes at all. I considered
28.
by constexpr 7y ago
Yes this was a surprise for me too. The benchmark I used for esbuild deliberately tests full build time without a cache, since that is an important metric to me. I assume Parcel is talking about incremental build times when the cache has al
29.
by constexpr 7y ago
> Have you tried using jemalloc? It can help a lot for situations like this. Huh, I thought Rust already used jemalloc by default. I looked it up and it looks like it was removed relatively recently. When I was doing this experiment, I w
30.
by constexpr 7y ago
It's cool to wake up in the morning and see my project on HN! For the record, I'm not trying to compete with the entire JavaScript ecosystem and create an extremely flexible build system that can build anything. I'm trying to

More ›