[Fluxbox-devel] Profiling Fluxbox

[<pet...@go...>]

Greetings,

   First off, excellent work creating a clean, functional, and intelligent W=
M=2E  I
thank you immensely=2E

   Now, on profiling=2E  I don't mean to say that fluxbox is slow; rather, I=
 was
curious at how little time was actually being spent by it since it is so sna=
ppy=2E
(I searched the devel-list for any conversations on the topic, and found
nothing=2E)

   (Take the following with a grain of salt; I am not a seasoned developer=2E)=


   As for my tests, all I did was add '-pg' to the CFLAGS and LDFLAGS for
compiling 0=2E9=2E9, and ran it directly from startx (no gdm/kdm etc in the
background)=2E
   To stress test it, I opened a few browser windows (in one desktop), a pdf=
 in
Adobe Acrobat (another desktop), gqview in another dt, and eog in another dt=2E=

Once the windows were open, I randomly jumped from desktop to desktop, openi=
ng
menus, moving windows, moving images, etc=2E  (This was not intended to be a=

precise test, just general curiosity=2E)  [Note: menu transparency is enable=
d=2E]
   In short, I created a typical workload and used it for approximately ten
minutes=2E

   What I found surprised me (somewhat):  57% of the usage was consumed by
FbTk::TextureRender::renderXimage, followed by 9% in TextureRender::pgradien=
t()=2E  Upon checking the source, I can see why=2E


   My observations/questions regarding renderXimage():

-) The function is 8-pages long!  (A great deal of this is a result of #ifde=
f's
regarding ORDERSPEUDO or architecture handling=2E)  What would be the advant=
ages
to breaking this into smaller chunks?  (if none other than to improve
readability)

(The following assumes vi does the proper brace pairing)
-) On line 512 (TextureRender=2Ecc, 0=2E9=2E9) there seems to be a random '}=
' that
throws off the entire 'if-else' structure=2E  (Check the pairing of the '}' =
on
line 559=2E)  I have little experience with C++, but shouldn't this throw of=
f the
whole definition?  In short, the opening brace for renderXimage() is closed =
by
the right-brace on line 559; what's with that?

-) Why are twelve variables declared with the 'register' directive?  I reali=
ze
the compiler is free to ignore this, but does it help/hinder the function in=
 any
way?

-) Finally, while this may seem obvious, has any optimization been attempted=
 on
the algorithm itsself?  I see it's derived from rastermans code, so I would
_assume_ it's efficient, but just figured I spark the question anyway=2E


   Thanks for all the work that has been done=2E  Fluxbox makes _using_ linu=
x alot
more enjoyable=2E

From the graphics illiterate newbie developer,
-- Peter