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

11–20 of 205 posts

Re: 4x Smaller, 50x Faster

#11

Post by cryptonector »

rektide wrote: post #3
lxe wrote: post #2

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

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 the value being "mutated" has more than one extant reference then mutation is done by copy-on-write.

If you manage to always have extra references, then "immutable mutation" gets expensive.

If you manage hold on to old references for a long time, then "immutable mutation" gets even more expensive.

In a run-time with a GC not based on reference counting you do have to GC all the intermediate garbage.

Immutable data structures really lend themselves well to reference counting GCs because you can't have cycles in immutable data.

Re: 4x Smaller, 50x Faster

#12

Post by xyzzy123 »

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…

I've always thought of immutability as great for situations where you want to "explore" (clone complex current state and go do some "what if"), need internal transactions, or allow time travel (snapshot/undo/redo) - situations where the state sharing is both efficient and feels "natural".

Also if the data/history are relatively small compared to the available memory it's a fine default that generally leads to "nicer" code.

Video doesn't seem at first glance like such a great fit.

Re: 4x Smaller, 50x Faster

#13

Post by azakai »

notacoward wrote: post #8
azakai wrote: post #5

Earlier quoted context omitted.

This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.

How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?

I'm not an expert on this, but one example is that immutability lets you operate safely on things in parallel. But JS VMs are not aware of objects that are immutable in Clojure's semantics, and in any case, do not operate on objects in parallel anyhow.

Re: 4x Smaller, 50x Faster

#14

Post by kccqzy »

xyzzy123 wrote: post #12
notacoward wrote: post #7

Earlier quoted context omitted.

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…

I've always thought of immutability as great for situations where you want to "explore" (clone complex current state and go do some "what if"), need internal transactions, or allow time travel (snapshot/undo/redo) - situations where the state sharing is both efficient and feels "natural". Also if the data/history are relatively small compared to the available memory it's a fine default that generally leads to "nicer"…

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.

Re: 4x Smaller, 50x Faster

#15

Post by kazinator »

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.

Re: 4x Smaller, 50x Faster

#17

Post by codetrotter »

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.

You can’t pause and rewind or skip ahead in a gif in any of the major browsers.

Re: 4x Smaller, 50x Faster

#18

Post by josephg »

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.

I fantasize about a future in which buying a faster computer means my software runs faster.

I don’t spend thousands on computer hardware so that lazy devs can get lazier.

Re: 4x Smaller, 50x Faster

#19

Post by eatonphil »

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.

I have no aversion to JavaScript. It's easier just to fetch the session as text and render it in the browser with JavaScript.

If you're building gifs then you need additional file storage and an async job queue for generating the gif. I try to avoid image processing personally.

Re: 4x Smaller, 50x Faster

#20

Post by memco »

notacoward wrote: post #8
azakai wrote: post #5

Earlier quoted context omitted.

This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.

How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?

> How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes?

Roc-lang, which is a functional, systems language in development uses something called opportunistic in-place mutation to do just that. Here's a video where the creator talks about it: https://youtu.be/vzfy4EKwG_Y?t=1276

Post reply on HN