Kuzma, I have the same idea in my mind for quite a long time, too.
This can be done easily with the following approach.
1. Replace every main(int argc, int argv) to <Program_name>_main(int argc,
int argv);
2. Modify CMakeLists and replace add_executable() with add_library() so
every components are now libs.
3. Add a thin wrapper binary program around the lib. The binary only
contains main.cpp and only has one function main(), which calls
<Program_name>_main().
4. Add a new program such as lxqt-shell, which loads the libs and all
component are running in the same process.
5. If any of the component crashes, the whole shell process crashes, but
the session manager can monitor this, and restart it. Though it's less
pleasant for the users, it should be a rare case and we should fix the bugs
anyways. This is also what Windows explorer.exe does.
6. For those who hates the monolithic shell process, they can still run
seprate components as different processes since we provide binaries in #3
which in turns call the component libraries.
Pros:
1. all major components are loaded in the same process. So memory, other
system resources, pixmap cache, menu cache, and all other caches in Qt can
be shared among all of them, potentially saving much RAM.
2. Loading will be faster, and synchronization between the components
becomes so easy and does not require IPC.
3. Interaction among the components can be done without IPC when they're
not running as separate processes.
4. Library symbol resolution is only done once by the runtime linker, so
loading should be faster. (However relocation might be increased, so the
final result is unknown).
5. No modification in the session manager is needed. Instead of loading
several components, it only need to load lxqt-shell and monitor it. The
only thing needs to be changed is lxqt-shell should be made configurable so
we can select what modules to load. A lxqt-config-shell tool is needed.
6. All parts can use the same pixmap cache for QIcon, which saves some X
resources and RAM.
Cons:
1. All components are compiled as PIC code, which might be larger and less
optimized.
2. One component crashes, the whole shell crashes. But if we separate the
shell process from the session manager, the user won't loss any data or the
processes they are running. Only the panel and the desktop manager
disappears, and if they can be auto-restarted, that's not a big issue, just
some glitches.
3. Since all programs are now using the same pixmap cache for icons, if the
icons used by different components are totally different, the cache will be
full sooner. Some old entries must be removed from the cache in this worst
case. Than, following calls to QIcon::pixmap() will have more missed cache
hit. That's the worst case which I think does not happen most of the time.
So basically, I think this idea is really worth for trying.
This should speed up the desktop a little bit and save much RAM.
What do you think?
On Wed, Nov 20, 2013 at 6:48 AM, Kuzma Shapran <leaf.on.w...@gmail.com>wrote:
>
>
> On 20 November 2013 11:41, Mark Deneen <mdeneen+l...@gmail.com> wrote:
>
>> If one module crashes, won't the entire process be terminated?
>>
>
> Alas, yes.
> We should just make sure modules never crash! ;-)
> Seriously, if panel or desktop app crashes - this is also not a very
> pleasant event. I remember that in Razor session monitors modules
> (processes) and restarts them if needed. With this new idea we also can
> have lightweight monitor app.
> When launcher starts - it register itself in the monitor app, before good
> exit it unregisters itself, on crash monitor restarts the launcher with
> needed modules.
> Actually, maybe the idea is not so bad.
>
> Cheers,
> Kuzma
>
>
>>
>> -M
>>
>>
>> On Tue, Nov 19, 2013 at 2:11 PM, Kuzma Shapran <leaf.on.w...@gmail.com>wrote:
>>
>>> I've just had a weird idea: make every part of DE as libraries and one
>>> application which just runs these parts alone or together:
>>> lxqt-launcher -panel -runner -desktop -whatever
>>>
>>> Cheers,
>>> Kuzma
>>>
>>>
>>> On 12 November 2013 22:41, Alexis López Zubieta <
>>> azubi...@estudiantes.uci.cu> wrote:
>>>
>>>> El 12/11/13 09:35, PCMan escribió:
>>>>
>>>> On Tue, Nov 12, 2013 at 4:58 PM, christ...@surlykke.dk <
>>>> christ...@surlykke.dk> wrote:
>>>>
>>>>>
>>>>> 2013/11/12 Jerome Leclanche <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> 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
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>> now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Lxde-list mailing list
>>> Lxde-list@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/lxde-list
>>>
>>>
>>
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
Lxde-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxde-list
