Re: becoming embebbed

On 30-Mar-2000 Tim Janik wrote:


> i guess the best solution so far has been presented by
>, i.e. suggesting to let gtk form
> a profile for certain applications that can be used to strip
> it down for specific purposes.

that was actually a really neat tidbit of wisdom, not only for embedded
systems, but other microsystems, like a system install program or custom
utility disk set... mix that and the fbdev target... :)

> another thing that hasn't really been mentioned here is, there are
> quite a bunch of places in gtk and glib where we trade memory for
> speed. while i don't suggest we actually trim structures to squeeze
> the last byte, there's still plenty of room for optimizations in
> the caching arena. i guess adding a configure option to optimize
> for memory and honouring that in a couple of code portions will
> have a greater impact than sorting out random widgets.

memory has been the most brutal hit for me personally, I have to pick the most
boring plain themes and stuff and find things I can kill to conserve memory. I
personally would be quite willing to trade some of that speed away for some
memory (sure, it's quicker to use an O(nlgn) algorithm instead of an O(n^2) ...
until you try running it in swap...)

would it be too much to ask for a --conservative-memory flag and #ifdef the
smaller/slower algorithms in place? (or put in the framework and some docs so
future gtk hackers/gnomers in the same situation as me can fill in the blanks)

The only box I have that doesn't suffer severe memory attrition is my bsd box
at work, and I can't code the stuff I love to code at work, I have to code icky
work crap... 


        -Erik <> []

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep

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