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

81–90 of 205 posts

Re: 4x Smaller, 50x Faster

#81

Post by aidos »

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.

I've been keeping an eye on your work for a long time now. We're a mobx shop so I was hoping to see you explore the ideas you had around that a little more (https://github.com/ryansolid/mobx-jsx).

I like and know where I'm at with React, but bringing a beginner through it recently definitely made me re-appreciate how nuanced it is. Also, you have to do a bit of voodoo to get good performance, and when you do the intention of the code vanishes pretty quickly.

For someone using React on top and mobx stores in the background (say 50k LOC all in), how big of a task would you say it is to move to something like Solid?

Re: 4x Smaller, 50x Faster

#82

Post by fnordsensei »

notacoward wrote: post #7
lxe wrote: post #2

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

This part... > for the high frame-rate, heavy animations this puts a lot of pressure on CPU and memory ...does seem to suggest that the "garbage multiplier" effect of immutability is an ill fit for applications that also create a lot of garbage naturally. Note that this is about as close to an apples-to-apples comparison as we're likely to get - the same application implemented two different ways - so it's not the ap…

Clojure developers are not unaware of the tradeoffs between immutable and mutable data structures. You'll see them use mutable data structures, particularly in tight loops inside functions that take immutable inputs, mutate them, and produce immutable outputs (thereby preserving the promise of immutability, while leveraging the performance of mutability internally).

You'll rarely see apps designed like this up-front though. Most of the time, the surgical mutability will come as a performance optimization pass later on.

As for the apples-to-apples part, I for one am unsurprised to see that WASM performs better than ClojureScript, particularly for an application like this.

Re: 4x Smaller, 50x Faster

#83

Post by fnordsensei »

cryptonector wrote: post #11
rektide wrote: post #3

Earlier quoted context omitted.

mutability is a data structuring virtualization but i'd just as much suspect the runtime virtualization. that the bundle used to be 570kB isnt an immutability issue. itcs that clojurescript drags in a whole clojure runtime, a new virtualization layer atop the js runtime. that, to me, is the most likely suspect. that said, for sure, short tbeow away high gc allocation patterns are generally not good. at work there's a…

Immutability is a drag if you create lots and lots of referenced state because, e.g., you want to hold on to many snapshots of past state. Immutability done right need not be much worse than mutability. For example, jq's internal value representation is immutable in appearance: - mutations yield new values, - but when the value being "mutated" has only one extant reference then mutation is done in-place, - while when…

> Immutability is a drag if you create lots and lots of referenced state because, e.g., you want to hold on to many snapshots of past state.

Isn't it the opposite? If you want to hold on to many referenced states at the same time, an immutable data structure should provide less overhead than a mutable one, due to structural sharing.

Re: 4x Smaller, 50x Faster

#85

Post by akavel »

kazinator wrote: post #15
eatonphil wrote: post #6

Historically asciinema was not easy to embed in React because you can't have multiple copies of React. So my team at the time wrote and open-sourced an embeddable alternative to it. Unfortunately that project seems to have disappeared by now. But now that asciinema is no longer in React maybe it will be possible to embed now. See https://github.com/asciinema/asciinema-player/issues/72#issu... .

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.

Is there some tool like this that you could recommend? I tried searching for one at one time for my project, assuming someone must have written something like that for the script command, but didn't seem to be able to find a reasonable one (or any? I don't recall). I ended up writing an ad hoc single use tool for gif-izing an asciinema transcript... (https://github.com/akavel/asciinema2gif)

Re: 4x Smaller, 50x Faster

#86

Post by fnordsensei »

badestrand wrote: post #80
fnordsensei wrote: post #79

As an enthusiastic Clojure/Script user, the new tech stack absolutely makes sense for this application. For the decrease in size, I expect most of the gain to come from dropping ClojureScript. For the speed increase, though, I expect most of the gain to come from WASM. JS and ClojureScript are within the same margin of error compared to the performance that can be achieved with WASM.

> Due to ClojureScript’s immutable data structures, there’s a lot of objects created and garbage collected all the time ^ From the article, sounds like a plausible cause for the speed difference.

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.

Re: 4x Smaller, 50x Faster

#87

Post by 1_player »

ReleaseCandidat wrote: post #76
omnicognate wrote: post #71

Earlier quoted context omitted.

Ew, people are using it for docs? It always seemed clearly to be for those quick-look demos on projects' home pages, and it's fantastic for that.

What exactly is the advantage of asciinema over a video or a GIF if you're just showing something? If I don't need to copy text out of it, it has the same function as a video.

It's definitely better than a GIF because you can seek forward. You never know when a GIF ends, and if you're distracted, you have to wait for it to loop back again.

Re: 4x Smaller, 50x Faster

#88

Post by agys »

For my own realtime browser based ASCII projects I update the DOM “manually”: the biggest bottleneck is frequent -horizontal- changes in color as each character with a new color needs to be wrapped in its own element. After all you can’t avoid a DOM repaint.

After several benchmarks I realized that the fastest way to update the entire window is to compose a string and assign it to each line/line-element via innerHTML. I usually get 60fps with 5-8k chars in fullscreen (browser text rendering has become really fast).

Post reply on HN