4 ms·
>and never just a function of the language you chose. I understand your point, but is important to know how NUANCED is this. Performance is MOSTLY driven by t
by mamcx 5y ago
>and never just a function of the language you chose.
I understand your point, but is important to know how NUANCED is this.
Performance is MOSTLY driven by the inherent design choices of each language(+ your own!). If you are on Gc, that choice is an impact for everything. Rust have Vectors as base, and lisp have GC-backed linked list. That is another deeeeep choice.
But IF you know (or hit the luck!) which are these designs, and understand that not matter which language everyone wanna gotta fast and most common operations (the ones for what THAT lang was designed for!) are fast enough... then all is ok, in average.
Is when you go against that design that you see how the illusion crack a little. Then, is all about how much you can workaround about it to recover most of the performance
- pjmlp 5y agoOr when one fails to understand what is actually available to them on the toolbox and only look for what is visible at top level. For example, yes Lisps have a GC backed linked list, but in the case of Common Lisp, they also have arrays, stack allocation and deterministic resource management macros.
- Zababa 5y agoThat is very true, for example Java, even while being as fast as Rust and Lisp, takes way more memory than both of them. My point was more for myself (and maybe other people that haven't heard a lot about performance), as I had very strict ideas about it, but thanks to articles like that I can understand how it's more nuanced. Software engineering and computer science are both really vast and deep fields, but a lot of information is here online, shared freely by awesome people. That means that for a lot of things, being aware of something is enough to make good decisions. These types of articles allows me to be more aware of the nuances of performance (and how complex it is as a topic). For example, if I'm just trying to optimize the speed of my algorithm, and only know Java, Java might be enough. But if I'm trying to optimize my cloud spendings, considering the memory consumption of Java, it might not be the best choice. Comments like yours are also a great way to learn more. I know that linked-lists are really good in Lisp (and OCaml too!), but with other languages there's not often the best choice.
- native_samples 5y agoWe don't really know how much memory Java needs on this benchmark. The JVM will use as much memory as you give it. Its viewpoint is, if you tell me I can use 300mb then I'll just not do any GC work until I've used 300mb. Why work harder? To know how much memory you really need, you'd need to keep shrinking the Xmx max heap size setting until performance becomes unacceptably poor. However, that isn't done here.
- Zababa 5y agoThat's a fair point, however the other programs use less memory out of the box without any need for tuning, so that's a win for them.
- AndrewDucker 5y agoNot using memory that's lying empty isn't a win. There's nothing better about "I didn't use a reusable resource that was lying about unused."
- Zababa 5y agoThe same could apply to CPU usage, which is what this whole article is about.
- pjmlp 5y agoOptimizing for the sake of optimizing is wasted money. If the customer has given you a 300MB budget and the application is able to perform its job with 180 MB, and keep the customer happy, there is no point paying for development costs to bring it down to 50 MB. There are other projects to move into, instead of burning money with non-existent project delivery acceptance criteria.
- Zababa 5y agoThe whole premise of this article was to optimize programs for speed, which is also pointless if your program is already fast enough. They also don't take into account programmer time spent to optimize the project, how easy it is to find programmers that work with that particular language and that can deliver performant software, etc. Your criticism is valid, but I feel like it should be applied to this whole article rather than this particular point. I like how stuff like that is described on the Computer Language Benchmark Game: "… a pretty solid study on the boredom of performance-oriented software engineers grouped by programming language.". You could also probably substitute "boredom" with "ego".