On Wed, 17 Nov 2004, Johan Forsberg wrote:
I realise by now inkscape is probably a much more complex program than sodipodi but I can't really see why the actual rendering should be slower. Is there a technical explanation for this or is something strange with my system?
Yes, there are technical reasons for the performance difference.
First, we've long been aware of certain error conditions in the Sodipodi renderer that would lead to crashes and other oddball behaviors in extreme cases. Part of the work we've focused on during the Inkscape development process has been to close those corner cases by ensuring 'mathematical correctness'. These extra checks can have some performance cost, but with the benefit of the renderer being more correct.
This approach is consistent with Cairo, which is even more attentive to correctness (and correspondingly has similar performance concerns.)
Second, the entire renderer itself has been rewritten. This work was initiated with the boolean functionality, and has enabled us to be able to implement a number of new features. The renderer's performance is not as optimized as Sodipodi's, however. We suspect this is not because the renderer cannot be optimized but rather simply because there has not been a sufficient amount of attention placed on optimization.
In fact, there has been concern that one issue we suffer from the Sodipodi codebase is that there were a lot of things optimized unnecessarily, which made the code more complex and frustrating to maintain. Thus there is a mindset in Inkscape to avoid random optimization in favor of a more scientific approach - make the code correct first, then measure out the specific areas where the code is slow through a process called profiling, and then optimize the specific functions or algorithms that will gain better results. However, developer attention lately has focused more on feature implementation, bug fixing, and code cleanup than on optimization; it's becoming clear that we may want to spend a release focusing on optimization - the project has done great at getting the bugs fixed and the code stable, so it makes sense to now really focus on performance.
In some cases, there are tradeoffs between features and performance; sometimes a really handy feature can only be obtained by adding code that will impose some slowdown in performance. It's possible that if we focus on performance we can find ways of implementing those features in ways that won't impact performance. I know there have been discussions along these lines recently, so am hopeful those situations will get worked out well.
The most important thing, I think, is to involve more people in participating in examining the performance. This can actually be done without a huge amount of experience with the codebase, although you do need to be quite good with C and C++.
Perhaps for 0.41 we could establish some performance improvement goals, like we've been able to do so well with bug count? E.g., select a few test conditions and aim to improve the total performance on those tests by 15% or something?
Bryce