4x Smaller, 50x Faster
blog.asciinema.org
4x Smaller, 50x Faster
1–10 of 205 posts
Re: 4x Smaller, 50x Faster
#2The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
Re: 4x Smaller, 50x Faster
#3The 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 lot of "functional" patterns, nary a for loop in sight. this endless .map() .filter() usage causes near exactly similar issues, with shortived objects. it seems ultra sad & silly to me. waste after waste. but i also think we have much more deeply rooted problems.
Re: 4x Smaller, 50x Faster
#4The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
[deleted]
Re: 4x Smaller, 50x Faster
#5The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.
Re: 4x Smaller, 50x Faster
#6Historically 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....
Re: 4x Smaller, 50x Faster
#7The 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 application's innate object-lifetime characteristics that are the problem. That's an implementation artifact.
The question is: how many applications are likely to hit this same limit? Is this a rare case, or is it common? If it's common, it is indeed an indictment of the "immutable" approach. Otherwise, not so much.
Re: 4x Smaller, 50x Faster
#8The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
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?
Re: 4x Smaller, 50x Faster
#9The 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.
Re: 4x Smaller, 50x Faster
#10The 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…
Are you sure about the short-lived allocations being a problem for the collector? My understanding of modern generational garbage collectors was that they performed quite well with short-lived garbage. Not as well as not creating the garbage in the first place, of course, but not so badly as to be a problem in most cases.