<story><title>Swallowing the elephant into Blender</title><url>https://aras-p.info/blog/2022/07/20/Swallowing-the-elephant-into-Blender/</url></story><parent_chain></parent_chain><comment><author>dahart</author><text>What a great example of how a series of reasonable decisions can add up to something unreasonable when you scale up the inputs. This line is my favorite: “there was an open task for a few years to address it (T73412), and so I did it.”&lt;p&gt;This situation reminds me a little bit of trying to work with very large images in ImageMagick, like 60k x 60k resolution. A simple resize was taking 6 hours on my mac 10 years ago, due to IM trying to allocate the whole image at once and then swapping non-stop. And then I discovered that the Graphics Magick fork did streamed resizing, and did the task in a couple of minutes. It’s a small and relatively easy change, but someone had to prioritize handling large inputs first. This is one reason software is hard for me; every time I need to process large inputs I wish I had written a streaming mechanism, but every time I start a project I decide to do the easy thing first and wait until I critically need streaming. Maybe it’s the right thing to do to avoid over-engineering, but this comes up often enough that I’m usually in a mild state of frustration about something being under-developed.</text></comment>
<story><title>Swallowing the elephant into Blender</title><url>https://aras-p.info/blog/2022/07/20/Swallowing-the-elephant-into-Blender/</url></story><parent_chain></parent_chain><comment><author>ludston</author><text>&amp;gt; The speedup factor is order-dependent.&lt;p&gt;This is why it is very difficult to justify optimization work to management. If there are 20 things to optimize that take 10 seconds each, the change isn&amp;#x27;t really noticeable until you&amp;#x27;re getting past half-way. And once your processing already takes a few minutes, what&amp;#x27;s the harm in adding another 10 seconds?</text></comment>