[Gimp-developer] your so called optimizations and why we don't like them

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel,

you recently checked in a huge change to GIMP that we (Mitch and me)
have been very unhappy with. In the meantime, I have gone through the
hassle of looking at every single line of your changes and I have
reverted most of it. Here are the reasons, why we think your
"optimizations" don't make sense and, even worse, are dangerous:


> Unsignify lots of variables and parameters

While unsigned variables can speed things up under very special
circumstances, they bear the danger of introducing subtle bugs that
are almost impossible to find. A good example is found in
pango/docs/TEXT/coding-style (a recommened read, btw.):
 
  If width is unsigned and 10, then:

   int new_width = MAX (width - 15, 1);

  produces 4294967291, not 1.


Also, in lots of places you've changed, the value -1 was used to 
indicate an unset value (width and height of GimpPreview for 
example).


> use bitfields in structs where possible

this is an optimizations of structs sizes. It does make sense to use
bitfields for boolean fields if large numbers of this struct are
allocated. For rarely used objects the gain in memory usage is
neglible however. Since the change makes the code less readable it
should be applied with care. The change again also bears the
possibility of introducing bugs. This happens when values others than
TRUE (1) and FALSE (0) are assigned to struct fields defined as
unsigned int : 1.  For this reason, this change should only be done
late in the development cycle. Once the API is settled and the code is
stable, we can think about converting booleans in frequently used
structs to bitfields. At the very moment, it doesn't make sense at
all.


> simplified logic thanks to bitfields

you changed code from
 gimp->be_verbose = be_verbose ? TRUE : FALSE;
to 
 gimp->be_verbose = be_verbose;

This is wrong, especially if a bitfield is used. I don't think I need
to explain the reason.


Daniel, would you please from now on inform us about the changes you
are working on and send patches to this mailing list instead of
applying your work to CVS without asking. It took me hours to revert
your changes and I don't want to have to go through this again. If you
think I reverted too much (which I'm sure has happened in a few
places), please send the relevant changes in small patches so we can
discuss them here.


Salut, Sven


[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux