Mailing List Archive: Maemo: Developers

Ideal way to develop a long-running app?

Index | Next | Previous | View Threaded

pkahle at pobox

Dec 19, 2005, 9:28 PM

Post #1 of 4 (1160 views)
Permalink

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 [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

igor.stoppa at nokia

Dec 19, 2005, 10:58 PM

Post #2 of 4 (1025 views)
Permalink

Re: Ideal way to develop a long-running app? [In reply to]

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 [at] maemo
> https://maemo.org/mailman/listinfo/maemo-developers
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

sampo.nurmentaus at movial

Dec 19, 2005, 11:09 PM

Post #3 of 4 (1033 views)
Permalink

Re: Ideal way to develop a long-running app? [In reply to]

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 [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at movial

Dec 20, 2005, 12:14 AM

Post #4 of 4 (1028 views)
Permalink

Re: Ideal way to develop a long-running app? [In reply to]

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 [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads