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!