21–30 of 68 posts
However there are other metrics besides performance that are worth caring about, e.g. readability, maintainability, etc...
Regarding the point "Don’t use floating-point operations when integers will do." I agree that using integer arithmetic can result in cleaner, easier to reason about code when applicable. It then follows that because of these traits the software will faster. But integer arithmetic is not necessarily faster than floating point arithmetic in general; see for example: https://youtu.be/3K2LmnaLLF8?t=31m10s .
> But integer arithmetic is not necessarily faster than floating point arithmetic in general; GPUs was the first place I feel like floats got a much better pathway than any other data type - graphical pixel manipulations also can get away with much higher arithmetic errors, because it's all going to get rounded down to a pixel eventually. On the other hand, the only place where I've really worked heavily with fixed p…
Softfp does not preclude the use of floating point math at all. It means you pay an extra cost when passing floats as arguments. (Which means you should rather use a hardfp math library if possible.)
“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…
Performance is always an issue. That said, I fully grant it may be an issue that is worth solving later in the process.
“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…
(https://www.stackbuilders.com/tutorials/haskell/ghc-optimiza...)
Software development is all about compromises, just like any kind of real world engineering. Building a stage for a weekend festival is different from building a bridge over a river. We're always on a budget, so if I can work much faster and safer and lose some marginal efficiency, I'll do it—unless marginal efficiency is what I'm competing on, which it usually isn't.
2. Make it right
3. Make it fast
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth
Earlier quoted context omitted.
Here it is: https://www.fpcomplete.com/blog/2017/07/iterators-streams-ru...
The key word is "often". Which means not always, which means you cannot rely on it unless you check all your code in Godbolt or equivalent.
“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…
Most languages are capabale of inlining the "next" function of the iterator to generate almost the same code as a regular for loop.
“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…
You give "map/filter/reduce" as an example and claim that theses approaches "typically result in passing over the data multiple times". No, since reduce can behave like map and filter, with a proper reduction function you only have to pass over the data once.
> Most collections/array I process have trivial number of elements (That is true for all other advice given in the original article, but not for this: A reduction function only needs one input element and the aggregate/result so far. This function then does not care whether it is called in the context of list or vector iteration, it will happily work with elements read from a stream or any other potentially destructive iterator. The benefit is obvious: Write & debug once, document and never touch the code again until the actual algorithm implemented there changes.
I think of myself as a software craftsman. Just like a master carpenter, the things I make should be not only functional but beautiful as well. Of course we should "care" about our work. However there are other metrics besides performance that are worth caring about, e.g. readability, maintainability, etc...
I also try to be a 'craftsman', and I try to pick work where that's an option, but I find that in practice, more often than not I have to care about various 'other metrics' at the detriment of craftsmanship.
Although I suppose being skilled at managing these various metrics could in itself be considered craftsmanship. And perhaps that mindset helps a bit with not getting utterly depressed at some of the shit I'm forced to deliver...