El 12/11/13 09:35, PCMan escribió:
On Tue, Nov 12, 2013 at 4:58 PM, christ...@surlykke.dk
<mailto:christ...@surlykke.dk> <christ...@surlykke.dk
<mailto:christ...@surlykke.dk>> wrote:
2013/11/12 Jerome Leclanche <adys...@gmail.com
<mailto:adys...@gmail.com>>
Yeah you mentioned this before. I'm not a fan of merging the
two; the
panel is especially a component users may want to change.
This needs more thoughts but it's a bit too early to care about it
imho. Maybe see what we do in the next 3-6 months and then
decide on
the two components.
J. Leclanche
I'd agree with Jerome. If I understand your mail you can save 6MB,
which is nice for sure but not _that_ much. And in terms of
functionality I don't see the panel and the runner as very closely
related. Let's get things working first. And then, maybe, we can
try to figure out how two applications can share a cache (of icons
and such)...
br. Chr.
On Tue, Nov 12, 2013 at 8:05 AM, PCMan <pcman...@gmail.com
<mailto:pcman...@gmail.com>> wrote:
> Hello,
> I just did some experiment yesterday.
> On debian, lxde-qt now eats 109 MB of RAM after a cold boot.
> On the same machine, the old lxde gtk+ version only used 85 MB.
> (On archlinux, it uses about 150 - 210 MB depending on the
machine.)
> The difference is quite obvious. :-(
> Though 109 MB is good, I think there's room to make it better.
> The most memory hungry programs are pcmanfm-qt, lxqt-panel,
and lxqt-runner.
> I already tried to optimize pcmanfm-qt earlier but it's not
possible to
> squeeze much from it since the wallpaper is a huge bitmap
and must eat some
> RAM.
> Other parts are hard to optimize as well. No obvious memory
eater was found
> during the profiling.
> Much RAM was used by the icon pixmap cache, but it's
inevitable. Otherwise
> we'll get slow painting.
> The other parts used most RAM were lxqt-panel, and then
lxqt-runner.
> I tried to put them together in the same binary, and tested
it again.
> If we merge lxqt-panel + lxqt-runner into a single process,
the used RAM
> becomes 103 MB after cold boot on the same machine.
> The drawback of this approach is, we cannot have an
independent lxqt-runner
> program.
> A simple way to fix this is making lxqt-runner a module -
liblxqt-runner,
> and let lxqt-panel load it.
> When a standalone lxqt-runner program is wanted, we can have
a simple
> program lxqt-runner which loads the lib. Both lxqt-panel and
lxqt-runner
> share the same liblxqt-runner.
> The drawback of this approach is also obvious. To make it a
library, the
> compiled code will be PIC, which is more inefficient and
less optimized.
> I'm not sure if this will really have impact on perceived
performance.
> Some more experiment needs to be done for it.
>
> Any comments?
OK, let's make it work first.
Thanks!
Hello:
PCman, as you, I also did some experiments to merge the different parts
of the desktop such as lxqt-panel, lxqt-runner and even the pcmanfm-qt.
My results tell me that we can save from 2 to 4 mb per application
merged so I consider that this approach should not be dropped. If we
make a modular design of each application we will be able to build then
standalone and as module of a big application. Other problem that I
found was that those application mainly the PcmanFm-qt are a bit
unstable when you just put then together. I will keep working on this
approach.
Best wishes
Alexis López Zubieta
Nova Light Development Team
University of Informatics Sciences (Cuba)
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
