While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.
4x Smaller, 50x Faster
51–60 of 205 posts
Re: 4x Smaller, 50x Faster
#52Earlier quoted context omitted.
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.
I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
I would.
Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it.
Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best practices that have cropped up in the past few years has been more for helping teams of people deal with growing code bases rather than helping programmers deal with limited hardware. In computer science this should be self explanatory. For optimal runtimes the act of making copies is avoided. Why people usually seem to ignore the fact that they're wasting cycles for the sake of the holy grail of clean, functional programming and immutability has eluded me.
Typescript, focus on immutability, microservices even. I hate all of them but they have their purposes. They solve people problems. Maximizing hardware performance is not in the list though.
Re: 4x Smaller, 50x Faster
#53Earlier quoted context omitted.
I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
I would. Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it. Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best pra…
Yeah now I wouldn't use immutable structure in an performance intensive application, but I do _hope_ one day we have some cycles to spare and can use it without worrying too much. To me it's like garbage collection, it's nice to have if we can afford some performance cost.
Re: 4x Smaller, 50x Faster
#54Earlier 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…
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.
This is true for small amounts of garbage but not for large amounts which is still slow and large is relative to the hardware your user is running on. It’ll also cause a death by a thousand cuts where it’s extremely difficult to dig yourself out of poor performance because the cause runs throughout the program.
It’s better to look at cheap short lived collection as a great way to get the thing you’re making working but ultimately something that needs to be cleaned up to be production ready.
Re: 4x Smaller, 50x Faster
#55Earlier quoted context omitted.
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.
You may call functional programmers who prefer immutable data structures lazy because we want to actually understand what we create, but I don't see how the 10 billion layers of abstractions and state duplications somehow end up making better software.
I'm not sure if you feel attacked or not but you shouldn't. Being lazy is good for programming I think. You should keep in mind that your functional programming base is built on a figurative 10 billion layers of abstraction already. It's just that those abstractions are somewhat well made so you don't have to think about it.
Proper abstractions aid in understanding and can ideally be optimized away. Poor abstractions hinder it and slow things down.
Re: 4x Smaller, 50x Faster
#56Earlier quoted context omitted.
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.
That ship sailed three decades ago.
Re: 4x Smaller, 50x Faster
#57While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.
It's a lean-back experience, like the difference between a book and a video. It does have its perks.
Re: 4x Smaller, 50x Faster
#58Earlier quoted context omitted.
I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
I would. Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it. Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best pra…
Abstraction is at the core of programming... complaining about people not "properly managing mutable state" is like complaining about choosing Java over C because they're not "properly" managing memory and instead using a garbage collector. Maximizing hardware performance is, truth be told, largely irrelevant for the vast majority of applications. If they can meet their goals/deadlines/whatever, you can call them lazy, but I think most would call them efficient.
Though I must admit, every time my browser lags when viewing what SHOULD be a static site, I do die a little inside.
Re: 4x Smaller, 50x Faster
#59Earlier quoted context omitted.
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.
"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 speed. Etc.
GC performance on short-lived objects is quite good in enough situations to matter, such that optimizing for it, rather than your application architecture, is likely foolish outside of performance sensitive loops.
Time is always limited. Spending your optimization budget on micro-optimizations is short-sighted.