a bit ot: performance vs clean programming (yt, 22 min)
https://m.youtube.com/watch?v=tD5NrevFtbU well, I guess in cinelerra case even just time to initially type in all that code was relevant :) but I found it quite heartwarming how someone finally noticed how nicely-looking code may perform ....suboptimally. So, I wish all programmers to find right balance between nice features and nice performance :)
On 3/2/23 08:02, Andrew Randrianasulu via Cin wrote:
https://m.youtube.com/watch?v=tD5NrevFtbU
well, I guess in cinelerra case even just time to initially type in all that code was relevant :)
but I found it quite heartwarming how someone finally noticed how nicely-looking code may perform ....suboptimally.
So, I wish all programmers to find right balance between nice features and nice performance :)
I guess the presenter has never heard of stuff like premature optimization inline, or static inline code reuse vs brute force tradeoffs supportability (writing code for others, not for yourself) He kind of misrepresents some things, but I don't blame him, per-se. I just don't think he has the software engineering sophistication to understand when different paradigms are called for. Much of my work is in the embedded systems domain, and I started coding on machines that had barely 4Kbytes of RAM so I'm no stranger to code optimization. I just think some things here are taken out of context to prove a moderately weak point.
чт, 2 мар. 2023 г., 23:07 Rob Prowel <[email protected]>:
On 3/2/23 08:02, Andrew Randrianasulu via Cin wrote:
https://m.youtube.com/watch?v=tD5NrevFtbU
well, I guess in cinelerra case even just time to initially type in all that code was relevant :)
but I found it quite heartwarming how someone finally noticed how nicely-looking code may perform ....suboptimally.
So, I wish all programmers to find right balance between nice features and nice performance :)
I guess the presenter has never heard of stuff like
premature optimization inline, or static inline code reuse vs brute force tradeoffs supportability (writing code for others, not for yourself)
He kind of misrepresents some things, but I don't blame him, per-se. I just don't think he has the software engineering sophistication to understand when different paradigms are called for.
Much of my work is in the embedded systems domain, and I started coding on machines that had barely 4Kbytes of RAM so I'm no stranger to code optimization. I just think some things here are taken out of context to prove a moderately weak point.
yet they have *some* point. I think for example this diff to ffmpeg's opencl tonemap filter IS table-driven, yet I have no idea how much difference it will make in image quality ... https://gist.github.com/sharpbai/5710e4bd06c35ce144e2945f1a9a7bb8#file-color... but because Karol Herbst was nice enough to fix rusticl on 32-bit hosts I can try this patch oneday :)
participants (2)
-
Andrew Randrianasulu -
Rob Prowel