Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? I think it might still make sense to make the long running process as small memory-wise as possible. Gtk UI has quite large memory overhead and you cannot really get rid of it after you've instantiated it without exiting the UI proccess. Most of the UI memory usage is really in the underlying libraries: - X socket buffer - Iconv stuff - Fonts and Pango/Xft/fontconfig initialization - Glib/Gtk class initializations - Style objects and data etc. (And with the large number of objects that Gtk and underlying stuff uses, memory fragmentation within process heap might also become an issue if application has very dynamic memory behaviour.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Ideal way to develop a long-running app?
Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? Thanks, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, you want to write a power savvy application, then. Few basic advices, which are also useful from a performance point of view (sorry if i'm stating the obvious but there's really no trick involved): -avoid polling: polling is generally bad, it's useful only for very tight loops that usually are not involved when writing apps -avoid busy looping (see polling): a significant amount of power is saved only when the processor is really idle, therefore ever call to sleep functions is fine, when you need to wait for something. If it's an asynchronous event that you are waiting for, then you can probably execute some sort of blocking call that will effectively prevent execution of your app until the data it's waiting for is really available -don't perform unnecessary activity: if the screen is blank, there is no need to update it, if you can manage to quickly redraw it when it's unblanked; however you can surely stops animations effects, such as glowing blinking and similar -don't abuse of connectivity resources like bt or wlan I hope this few points will help you br, igor On Tue, 2005-12-20 at 00:28 -0500, ext Peter Kahle wrote: Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? Thanks, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? As an approximation, I did run the example googletalk VOIP/IM commandline client shipped with google's libjingle and when connected to google talk and having buddylist loaded with no VOIP call going on, it took some 2.5Megs on ARM as resident size. Rough estimate I know, but gives some idea about the memory requirements of an IM running without GUI. To eliminate the process overhead, one could link the libjingle with a StatusBar plugin. Then the parts of the IM that are always running, would run in the same process with the desktop. :-) Of course it could then also crash the desktop too... But in this case one could use the plugin to show dialogs on incoming messages/calls etc. Then when needed, just launch the actual GUI. Might work, but does not have a beautifull architecture as your idea about a backend running. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
