I agree - it's worth a try.
And you have raised an interesting point about IPC.
If the session starts (and monitors) only one instance of lxqt-shell, then
it's not a question - all modules are libraries within the same process,
but we allow to start several separate processes of lxqt-shell (we might
even have a checkbox in session config: "launch components as separate
processes"). In this case modules should find out themselves how to
interact with other modules - through IPC or using direct calls (or
signal/slots or whatever) within the same process.
Fortunately there should not be many of IPC calls, so lxqt-shell can do
this by redirecting requests to another loaded library or by sending them
to session or to another instance of lxqt-shell.
Another point to consider - is singletons. Most (if not all) our modules
should be singletons. So it has to be tracked somewhere. The only stable
point is session, so when a lxqt-shell tries to start a module - it should
ask session whether this particular module is allowed to start.
Cheers,
Kuzma
On 20 November 2013 16:05, PCMan <pcman...@gmail.com> wrote:
> 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
