Hi DeVont, thanks for your suggestions & interest in contribution. I'm not really a GIMP developer and am definitely not familiar with the codebase, but I'm deeply familiar with software engineering/ re-engineering & I'll just give you a few comments on first principles. > 1. gimp/libgimpmath/gimpmathtypes.h (file in > question:gimp/libgimpmath/gimpmatrix.h(c)) > > This file declares math structures that gimp uses like vectors and > matrices. The GimpMatrix structure come in 2X2, 3X3 and even 4X4 versions. > Each matrix is a 2Dimensional gdouble array with the appropriate amount of > elements to span the NXN matrix.I believe this data structure is used for > computation during image editing. There are functions handling > comparisons, identities, transformations, rotations, translations and > various other matrix operations. > > Possible changes: I believe the declaration of 3 special kinds of gimp > matrices can be generalized to a struct (or class) that holds and defines > an NXN matrix. Generalizing these structures, would almost certainly make them slower. While in peripheral areas that might be fine, I do not think GIMP users wish to lose performance on matrix-based image transformations. Neither am I aware that there could ever be a need for matrices larger than 4x4. So, I probably recommend against pursuing #1. > 2. gimp/app/core/gimpcontainer.h > This class contains a data structure that is used to store different things about the > various objects in gimp. It works hand and hand with the GimpObject class. > This class uses what I believe to be some form of tree or heap structure. The > class refers to add, remove, reorder, and getChild functions that are defined > across the class. The gimp.h code uses the GimpContainer class pointers for everything > from fonts, to documents, to displays. As this data structure is used with > GimpObject (which controls a large amount of functionality in gimp) and is > heavily referenced in the gimp.h file, optimizing this class could go a long way in > optimizing the code. This area is probably more productive for investigation. You will need to take some measurements/ benchmarks, to verify whether your changes are delivering an actual performance improvement -- and by how much. If you document the number of calls into this data structure/site, measure performance beforehand, trial various changes, measure & document performance from each version, write the results up formally and submit code (if any) you will have completed your assignment fully. I am not assuming that you will be able to improve performance, this may be quite possible but even measuring & investigating thoroughly and coming to the well-supported conclusion that you can't, would be a very competent completion of your assignment. > If we decrease the amount of time to ?reorder? the tree, then we decrease the amount of time > several other objects take to be initialized and added to the tree. Well, it sounds quite plausible! But only the measurements can tell. > 3. gimp/libgimpmath/gimpvector.h(c) > The GimpVector data structure keeps track of axis orientations and lengths. > I believe this is used in the various drawing tools. I also believe the > automated shapes functions may use it for drawing polygons. The vector data > structure is a structure that holds four gdouble variables that are > separately declared (gdouble x, y, z, w for the 4axis vector for example). > There are three versions of the gimp vector: 2axis, 3axis, and 4axis. A potential change to > GimpVector could be altering the way that it is stored like we plan to > change the GimpMatrix. This means making a streamlined generalized vector that can be of > dimension N. I didn't like the GimpMatrix idea, due to reduced efficiency of very-heavily used code. I expect the GimpVector may also be quite heavily used -- perhaps less so than GimpMatrix, but I would have to be convinced it was not performance-critical. "Unrolled loops" -- and thus separate size-specific implementations, as per the existing code -- are the best design choice for performance-critical code. Implementing a variable-length vector/list will, I expect, be vastly slower than using a fixed-size struct or array. Structs and arrays are much more efficient to allocate & de-reference.. Perhaps comparing such codes on a testbed might give you a better idea/assessment of the potential relative performance? IN CONCLUSION: It's great that your group is interested & willing to challenge yourself, by taking a look at some serious large-scale software. I think #2 (GimpContainer/ the heap) sounds like the most plausible area for investigation & optimization. Make sure you measure & benchmark in a reliable way (warm-up first, # of iterations, etc) -- you may need to write some scripts or support code to enable this. Be sure to write up all your initial measurements, different approaches, results & conclusions. Good luck! _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
