Hacker News Reader

Comment by stiff | Hacker News Reader

estimated that the PS codebase could be reduced from 3,000,000 LOC to 30,000 LOC (=100x!!)

I challenge anyone making such claims to construct an even _moderately_ realistic example of where such reduction would be possible.

Here is a very simple and already very optimistic model that is still way below a 100x reduction: say my program consists nearly exclusively of sorting of various arrays and I write out bubble sort in full each time using for loops etc. rather than call a sort() procedure. Bubble sort takes roughly 20 lines of code to implement, so I would at best get a reduction of close to a 20x, rather than a 100x one.

View on HN

I don't doubt that your conclusion is correct, but what if the sort is used in 10 other functions, each of which is used 10 times? If you inlined everything you would end up with 100 copies of bubble sort. The code blowup is exponential in the level of nesting.

Indeed. Another venue for why it cuts out code is that it makes code more reusable. As a result, you are more likely to integrate nicely with already written libraries than write your own code. Technically, this is a way of reducing your codebase as well lol.

I doubt the 100x range, too, but Photoshop is decades old and, likely, has lots of its filters written in assembly for speed, with zillions of variants for all kinds of sometimes long gone CPUs and GPUs. It also still may have its own memory manager.

It that is true, it should be possible to get large wins in LOC if one either is willing to give up orders of magnitude in speed and memory usage, or is equipped with a sufficiently advanced compiler.

There likely also is some room for improvement if one is willing to change the file format (.psd is not known for its consistency), but that would likely be a rounding error.

Reducing a single bubble sort in code size doesn't do much, because it is used many times and its code size cost is well amortized. However, if you had many bubble sorts coded in your program with special cases, then consolidating those into one very abstract/parametric version could be a big win.

The reduction comes from making the code way more abstract and much more difficult to reason about in concrete contexts. So ya, it is probably possible, but no, our heads might not be very capable in writing/maintaining/debugging such code even if the computer could execute it. As an extreme, consider "very small code" contests in the demo scene, where various crazy tricks (self modifying code) are used to drastically reduce code sizes, none of which would ever be used in practice and have little SE value.

I'd expect more opportunities for reduction in code size to arise when you use fancy algorithms (not sorting) on generic algebraic structures that have many models in your program. For example, when I was a student, I implemented a library of numerical methods for my own use in class. It benefited a lot from being implemented as generically as possible.

That being said, a 100x reduction in code size seems like an exaggeration.

Reply on news.ycombinator.com