Clem Cole and Russell Williams discuss Photoshop's long history with parallelism, and what they now see as the main challenge.
Over the past two decades, Adobe Photoshop has become the de facto image-editing software for digital photography enthusiasts, artists, and graphic designers worldwide. Part of its widespread appeal has to do with a user interface that makes it fairly straightforward to apply some extremely sophisticated image editing and filtering techniques. Behind that façade, however, stands a lot of complex, computationally demanding code. To improve the performance of these computations, Photoshop's designers became early adopters of parallelism through efforts to access the extra power offered by the cutting-edge desktop systems of the day that were powered by either two or four processors. At the time, Photoshop was one of the only consumer desktop applications to offer such a capability.
Component models can help diagnose architectural problems in both new and existing systems.
The ever-increasing might of modern computers has made it possible to solve problems once thought too difficult to tackle. Far too often, however, the systems for these functionally complex problem spaces have overly complicated architectures. In this article I use the term architecture to refer to the overall macro design of a system rather than the details of how the individual parts are implemented. The system architecture is what is behind the scenes of usable functionality, including internal and external communication mechanisms, component boundaries and coupling, and how the system will make use of any underlying infrastructure (databases, networks, etc.). The architecture is the "right" answer to the question: how does this system work?
Excuses, excuses, excuses!
Using my favorite Greek passive-present-neuter participle (I trust you have one, too), I offer a dramatic prolegomenon to this overdue column. To wit, an apology and an explanation for its tardiness. (You'll notice the potentially unending recursion, since both column and excuses are late.) The apology is easy: we Brits just say "Jolly sorry, actually," and project a pained sincerity, whether we mean it or not.
Improving the performance of complex software is difficult, but understanding some fundamental principles can make it easier.
When I joined Oracle Corporation in 1989, performance was difficult. Only a few people claimed they could do it very well, and those people commanded high consulting rates. When circumstances thrust me into the "Oracle tuning" arena, I was quite unprepared. Recently, I've been introduced to the world of "MySQL tuning," and the situation seems very similar to what I saw in Oracle more than 20 years ago.