El 12/11/13 09:35, PCMan escribió:
Hello:On Tue, Nov 12, 2013 at 4:58 PM, email@example.com <firstname.lastname@example.org> wrote:
2013/11/12 Jerome Leclanche <email@example.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.
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)...
On Tue, Nov 12, 2013 at 8:05 AM, PCMan <firstname.lastname@example.org> wrote:
> 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
> 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
> 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!
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.
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
Lxde-list mailing list