On 1/14/07, Dominik Vogt <[EMAIL PROTECTED]> wrote:
On Sun, Jan 14, 2007 at 08:36:31PM +0000, seventh guardian wrote:
> Hello
>
> I have a question regarding one aspect of the coding: is it better to
> use big "do-everything" functions or "do-one-thing" ones?
It's better to use do-one-well-defined-thing-and-do-it-well
functions. Personally I try to cling to the Linux kernel coding
conventions, and they won't harm fvwm.
> I explain :)
>
> For instance HandleModuleInterface is a big function that, like the
> name suggests, does everything it may possibly be done with module
> input: it reads the module input, verifies that there's no error,
> checks for an expected string if that was asked, enqueue or execute
> according with the "enqueue" parameter.
>
> One "problem" with it now is that it requires that the "window" is
> read separately (to test for a dead module), otherwise it would
> require a return parameter to detect this.
>
> Other thing, the parameters given to it don't change much. In
> My_XNextEvent it is always asked to enqueue and not to expect. The
> other places where it is called is in PositiveWrite (if the module
> should lock) and in CMD_ModuleSynchronous. These are the places where
> it does use the expect value, but doesn't enqueue. These last
> situations are both rare.
>
> So what I thought would be better was to have small functions that
> don't need the current decision logic: one to input, other to execute,
> another to enqueue and another to test for the expected value.
>
>
> Smaller modular functions are usually better visually and
> maintenance-wise, but the other important thing is performance.
>
> So (for instance) in the most frequent use-case, My_XNextEvent, we
> would just call the module_receive function and pass its return value
> to the enqueue function. The question is, does calling two small
> "just-do-it" functions bring [much] more overhead than calling only
> one big "conditional" function?
(I assume we're talking about module input).
In comparison to X input, module input is rare (except maybe while
moving windows in the pager). Without any testing, I postulate
that the amount of I/O is roughly this:
I/O type frequency amount of data
-----------------------------------------------------
X Input very often some small packets
X Output sometimes some small to huge packets
Module Input rare some small packets
Module Output often tons of smal packets
So, the I/O types to optimize are handling input from X and
sending output to the modules.
> If the possible added overhead isn't that important, I would like to
> eventually apply my (unfinished) local changes to cvs. They make the
> module code much more "modular" :-)
Hm, did someone mention releaseing 2.5.21? This should be done
before (I think the code is ready to be released).
I did so, but since I thought I would have time to clean things up I
started committing harmless changes. Right now the only issue could be
a small lack of "cleanliness", which shouldn't affect the compiled
result at all. I confess, the code is a bit messy right now..
Should I undo my current patches and do them after the release?
Cheers
Renato
