Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

4x Smaller, 50x Faster

blog.asciinema.org

Post reply on HN
Print view View original

101–110 of 205 posts

Re: 4x Smaller, 50x Faster

#101

Post by ncmncm »

jdlshore wrote: post #59
ncmncm wrote: post #49

Earlier quoted context omitted.

"Perform quite well" is always relative to some reference. The oldest trick in the book is comparing to something even slower and saying "see? fast!". GC apologists seek to normalize this behavior. They often succeed, at that. Performing quite well against actually fast things, less often.

You seem to have an axe to grind. Performance isn’t black and white. Optimizing your memory usage isn’t going to do you a whit of good if you’re constrained by your database queries. Optimizing your DB queries isn’t going to do you any good if you’re constrained by a chatty microservice architecture. Optimizing your UI response time isn’t going to do you any good if you’re already below the threshold of perceived spe…

Meaningless personal criticisms undermine your argument.

Performance problems usually appear in places we prefer they would not, often runtime apparatus we poorly control such as GC. It is always preferable to try to ignore and discount those, as they may be arbitrarily hard to fix, so people do.

Yet, actually not depending on such apparatus, where it is the problem, gets you free optimization.

Performance doesn't care where it is found or lost. Micro-optimization is foundational; fail there, and there is often little else you can usefully do. The best optimizations are not doing the thing at all. GC is always strictly worse than no memory management.

Fixing your chatty microservoices and your under- or over-indexed DB queries may do you no good if you have built in bottlenecks of your own.

"Quite good" means nothing except in comparison to something else.

Re: 4x Smaller, 50x Faster

#102

Post by sickill »

cunthorpe wrote: post #30

Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library. I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.

The player has other UI parts, mainly the control bar with current time, progress/seek bar, full-screen toggle etc. Of course it could be built with plain JS but a small library like Solid.js does the job well.

The terminal lines with (colored) text definitely don't need a view library if you just want to display it, true. Canvas would be way more efficient here, and it's not out of the question for the terminal part in the future. One thing that using DOM (spans here) gives for free is copy-paste. Like you mentioned it could be solved by overlaying a text element on top of canvas (on mousedown, or when paused) or custom implementing copy-paste for canvas with mousedown/mousemove/mouseup, but that's all extra work, and as I mentioned in the blog terminal emulation was the bottleneck, not rendering.

Re: 4x Smaller, 50x Faster

#103

Post by sickill »

titzer wrote: post #22
kccqzy wrote: post #14

Earlier quoted context omitted.

Video can be played backwards and forwards, can be sought, or jumped to a particular point in time. It fits well with the "time travel" benefit of immutable data structure. The author mentioned it was extremely easy to implement some kind of a checkpoint or key framing with immutability. That's exactly using immutability to its strength.

The downside of immutability is the sheer volume of data (in the form of pixels) that needs to be pushed around. A single 4k frame is 8.3 million pixels, so you are looking at over 30MiB of data for 32-bit color, and you gotta push 30, maybe 60 of those a second. Maybe if you have a really good garbage collector (or a custom one, because frames are all the same size) you can get away with allocating that much data an…

That's not how asciinema-player works though. The player internally represents the terminal buffer as a grid of characters. So for 80x24 terminal you have 80*24=1920 grid cells, each keeping a unicode char + color attrs. When rendering the adjecent cells of each line are grouped by their common color attrs, resulting in (usually) a small number of span elements with text and proper style/class. You can see this in action by going to asciinema.org, opening a random recording, pausing it, then inspecting the terminal with browser's DOM inspector.

Re: 4x Smaller, 50x Faster

#104

Post by fnordsensei »

sickill wrote: post #98
fnordsensei wrote: post #86

Earlier quoted context omitted.

It's almost certainly part of it. I doubt that a ClojureScript application written mutably (which you can do) would compare favorably to WASM regardless.

Before attempting JS/Rust rewrite I tried using transients [0]. I converted small part of the vt code to use mutable data structures to see if it's giving any improvements. It barely did, the difference was negligible. I believe it was because I didn't go all the way, so the perf critical pieces deep down were still using immutable data structures. Maybe it would bring decent improvement if I converted most of the vt…

I get that. And then you'd have to find a way to get rid of React (and Reagent/whatever was used on top of it) to get it all the way to as lean as possible. At this point, you'd be leveraging almost nothing that ClojureScript brings to the table, while getting most of the cons.

Re: 4x Smaller, 50x Faster

#105

Post by sickill »

comma_at wrote: post #65
josephg wrote: post #38

Earlier quoted context omitted.

I agree - I think having 10 billon layers of abstraction is worse for everyone. It’s buggier, more expensive to make and (ironically) often slower in practice anyway; because you can’t optimize what you can’t understand. Java style OO has a lot to answer for. Functional programming is great. What’s not great is loading the entire closure VM environment into my browser - resulting in the software running (in this case…

> What’s not great is loading the entire closure VM environment into my browser There's no VM in clojurescript, it compiles to JS, it is tree-shaken and heavily optimized and minified through Google's Closure compiler. > resulting in the software running (in this case) 50x slower The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives.…

> The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives. The same can be done in clojurescript or javascript.

More or less, yes.

The majority of the perf increase here came from two things: 1. going from immutable->mutable, 2. going from CLJS/JS->Rust in the perf critical part. Doing just 1. would likely improve the performance, but not as much as doing both 1. and 2.

Doing just 1. while staying with ClojureScript could potentially be accomplished with transients [0] at the cost of making a major chunk of the code non-idiomatic Clojure. I actually played with transients here before attempting the rewrite, but haven't got too promising results though.

[0] https://clojure.org/reference/transients

Re: 4x Smaller, 50x Faster

#106

Post by gpderetta »

slmjkdbtl wrote: post #9
lxe wrote: post #2

The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.

I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.

That future is our past. The era of free, continuous order-of-magnitude single threaded CPU improvements is well behind us. Performance is only growing very slowly. On the other hand ram, disk, and network bandwidth/latency is improving continuously, making the CPU even more of a bottleneck.

Re: 4x Smaller, 50x Faster

#107

Post by sickill »

ryansolid wrote: post #16

It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.

Thanks Ryan! And thanks again for your work on Solid.js.

Re: 4x Smaller, 50x Faster

#108

Post by kazinator »

5e92cb50239222b wrote: post #44
kazinator wrote: post #15

Earlier quoted context omitted.

Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.

Those are pretty heavy unless it's only a second or two (then why would you need a gif at all?) You'll be further cutting your target audience to the extremely privileged. I've had to suffer with dial-up (3-4 KB/s) until 2009, and with shitty ADSL (15-30 KB/s) until 2013. Many parts of the world are still like that.

I have a here 90 second .gif I made a year ago (demo of a particular Vim syntax highlighting scheme for a commit message format). It contains 930 frames, 10 fps. The resolution is 1200x768. The .gif is 600.0 kilobytes, so the coding density is about 660 bytes per frame.

Someone downloading at 3-4KB/s might find the download annoying; on the other hand, it could play back on a 66 MHz 486 DX they found in the dumpster. Good luck bringing up a modern browser with Javascript.

4KB/s second would be enough to get it to average around 6FPS in the first pass through the animation, if it were being rendered as it is being downloaded.

Re: 4x Smaller, 50x Faster

#109

Post by sickill »

fnordsensei wrote: post #104
sickill wrote: post #98

Earlier quoted context omitted.

Before attempting JS/Rust rewrite I tried using transients [0]. I converted small part of the vt code to use mutable data structures to see if it's giving any improvements. It barely did, the difference was negligible. I believe it was because I didn't go all the way, so the perf critical pieces deep down were still using immutable data structures. Maybe it would bring decent improvement if I converted most of the vt…

I get that. And then you'd have to find a way to get rid of React (and Reagent/whatever was used on top of it) to get it all the way to as lean as possible. At this point, you'd be leveraging almost nothing that ClojureScript brings to the table, while getting most of the cons.

Spot on.

Re: 4x Smaller, 50x Faster

#110

Post by kazinator »

sickill wrote: post #92
kazinator wrote: post #15

Earlier quoted context omitted.

Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.

> no third party websites FYI you're not forced to use asciinema.org for hosting the recordings, it's fully self-hosting friendly: https://github.com/asciinema/asciinema-player/#quick-start

I don't want to engage in anything by the name of "hosting" to convey an animation.

Last time I made an animation, like this, over a year ago, I just pasted it into a team Slack channel.

Post reply on HN