Loading Speed

[iamasmith]

I think the only thing that's slightly disappointing about the PDAXROM distribution really now is the loading speed for applications which are becoming practical and preferrable to use.

For example Firefox, compared to dillo there's no contest you have to have it and use it and it always grinds waiting for it to load. Then there's Kopi KAddressbook and KAlendar, very pretty but big and slow to load.

So any ideas on how to improve load times ?

Here's one that may work, loop mounted file systems are going to initially bring into cache some portion of the file system simply by mounting. Cramfs, ZISOFS or Squashfs will certainly help by compressing what is loaded into the loop device the issue is firstly quantifying benefits then producing an environment that isn't limited too much by the fact that these file systems are read only.... If performance can be made to bear fruit then it shouldn't be too difficult to contruct an IPK package manager that runs on the desktop, builds your loop fs (of whatever flavour you like) and then transfers it to the Z to be used there.

So what do you think ? Is this a viable route to improving loading times if we can retain nearly the flexibility that we have with everything in a RW file system that can be 'ipkg update(d)'

Wacky idea or some merit ? any other ideas ? I can't be the only one that wishes things were a little snappier but would get HANGED by my wife if I bought an OQO to side step the issues ?

- Andy

[samxiao]

I think the only thing that's slightly disappointing about the PDAXROM distribution really now is the loading speed for applications which are becoming practical and preferrable to use.

For example Firefox, compared to dillo there's no contest you have to have it and use it and it always grinds waiting for it to load. Then there's Kopi KAddressbook and KAlendar, very pretty but big and slow to load.

So any ideas on how to improve load times ?

Here's one that may work, loop mounted file systems are going to initially bring into cache some portion of the file system simply by mounting. Cramfs, ZISOFS or Squashfs will certainly help by compressing what is loaded into the loop device the issue is firstly quantifying benefits then producing an environment that isn't limited too much by the fact that these file systems are read only.... If performance can be made to bear fruit then it shouldn't be too difficult to contruct an IPK package manager that runs on the desktop, builds your loop fs (of whatever flavour you like) and then transfers it to the Z to be used there.

So what do you think ? Is this a viable route to improving loading times if we can retain nearly the flexibility that we have with everything in a RW file system that can be 'ipkg update(d)'

Wacky idea or some merit ? any other ideas ? I can't be the only one that wishes things were a little snappier but would get HANGED by my wife if I bought an OQO to side step the issues ?

- Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63254\"][{POST_SNAPBACK}][/a][/div]

honestly speaking.. OZ's new 3.5.2 are extremely fast compare with pdaXrom right now

can we learn something from OZ's new kernel?

[ced]

and about consolidating the OZ/familiar GPE version with the pdaxrom team? :-) I "think" is better than copy each other... I don't really see any difference between the 2 version, same goal... just to bring X to the pda.

My 3 cents.

[iamasmith]

Umm, not sure if this is right on the lines. Do you have any experience of load times for things like Firefox on GPE ? Is it radically faster ?

The big difference between GPE and PDAXROM at the momement seems to be around the fact that most core GPE apps are designed 'lite'. For example the addressbook and calendar on GPE are nice and small, load quickly and use sqlite to store their information (there's actually a multisync plugin too but you need to pfaff around with sqlite and replace it with a networked version that they have on their feed).

PDAXROM, however, seems to currently be focussing on fully fledged apps. Some are big and have large library dependencies. I think we are therefore experiencing bottlenecks on the flash file system performance.

The idea behind using a loop device with a compressed file system should theoretically help to move the bottleneck away from the flash because since the libraries/programs are compressed you will get far more of each into a block on the loop device with a single read. The bottleneck may then move to the decompression routines used to expand the files, however, squashfs is particularly fast so it may well help.

So, does that fit with your experience of GPE ?... I presume you are talking about GPE here and not OPIE. OPIE would be snappy anyway because more rendering is handled by the OPIE 'Display Server' whereas with X you have a primitive X server and the application defines a lot of the look and feel by loading and usinig a widget library and probably some whole framework library if it's based on GTK/GTK2., hence a lot more needs loading at application startup than with an OPIE or for that matter QTopia environment.

- Andy

[pgas]

Iamasmith, you are right, the applications in gpe or opie are designed for hardware that were less performant that the SLC-series, firefox is designed for speed on modern pcs....

hence gpe apps load faster.

The drawback of gpe or other apps designed for compaq  being very fast is that they are simple, some applications for instance might even have 320x240 resolution hard coded and thus might need some work to be acceptable on pdaxrom.


I don't think you'll find much difference in the loading time of dillo on OZ/GPE and on pdaxrom.

kopi might load faster on oz/opie, as the qt lib are allready loaded.

I don't know about oz/opie, but sharp roms are using a trick to preload applications, this way  some pim applications can be preloaded and  start instantly. I know nothing about how this is implemented though.


Maybe we can simply hack some script/ windows manager so that some apps are never closed but simply minimized?

[iamasmith]

IMaybe we can simply hack some script/ windows manager so that some apps are never closed but simply minimized?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63312\"][{POST_SNAPBACK}][/a][/div]

OK, tried squashing /lib and /usr/lib and mounting over the existing directory points. Results were exactly the same.

kopi about 12 seconds to startup
firefox about 50 seconds to startup

(I've got apache running in the background, it may be slightly faster for some)

So the loop/squashfs theory doesn't hold water. I like the idea of launching the apps and having quick switch though. Maybe something in Matchbox may be able to help us here ?

Actually as a Desktop Manager fluxbox may provide a better answer for me becuase at least it holds a minimised state of the apps on the taskbar but when I looked at it last it had some dependency on a version of tslib that wasn't in RC8 and I didn't want to hose my install by installing it.

UPDATE: Actually fluxbox is fine it's vdesk that requires imlib to be installed (part of the fluxbox theme package uses vdesk). - actually vdesk needs a lot of dependency stuff and doesn't seem to install directly from the feed so you need to install it yourself.

Gosh this looks so cool now !

- Andy

[cpuffer_zaurus]

One thing that might help would be to create a wrapper program (or modify the applications) so that would prevent double launches. I often slow down my applications by double clicking thinking I did not start the application or by not realizing it is already running starting a second copy.

The basic idea would be if the program is running simply bring it to the desktop (as if it was picked from the active applications list) if it is not running then start it. There are of course a few race conditions like when the application is starting or stopping. these would need a little work but should be solvable.

Charles Puffer

[cpuffer_zaurus]

For dynamic libraries it might be posable to wright an application that loads the libraries but does not use them? This would be like a loop back but would reduce the copies in memory by 1. The application could be hard coded with the most common libs or it could learn by watching what was loaded.

Charles Puffer

[iamasmith]

One thing that might help would be to create a wrapper program (or modify the applications) so that would prevent double launches.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63320\"][{POST_SNAPBACK}][/a][/div]

Hmm, sounds like the sort of thing that a desktop manager might do for you already.... I wonder if there's something that can go into the .desktop file that might make this happen....

[iamasmith]

Hmm, sounds like the sort of thing that a desktop manager might do for you already.... I wonder if there's something that can go into the .desktop file that might make this happen....
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63345\"][{POST_SNAPBACK}][/a][/div]

Well I have found reference to a SingleInstance flag but it doesn't seem to be implemented by Matchbox-desktop

[jerrybme]

IMaybe we can simply hack some script/ windows manager so that some apps are never closed but simply minimized?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63312\"][{POST_SNAPBACK}][/a][/div]

Actually as a Desktop Manager fluxbox may provide a better answer for me becuase at least it holds a minimised state of the apps on the taskbar but when I looked at it last it had some dependency on a version of tslib that wasn't in RC8 and I didn't want to hose my install by installing it.

UPDATE: Actually fluxbox is fine it's vdesk that requires imlib to be installed (part of the fluxbox theme package uses vdesk). - actually vdesk needs a lot of dependency stuff and doesn't seem to install directly from the feed so you need to install it yourself.

Gosh this looks so cool now !

- Andy
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63316\"][{POST_SNAPBACK}][/a][/div]

You might try fvwm, I believe it's fast than fluxbox, certainly more configurable. Zumi did a great job of creating a taskbar applet. I'm currently using it with X-Qt-Debian and it is faster than icewm
Cheers,
Jerry

[iamasmith]

Well fluxbox seemed quite nice but there's been so much effort put into getting matchbox right including the eject applets for your CF/SD cards that I hadn't realised just how good the PDAXROM team had made their Matchbox implementation.

Well back to Matchbox then....

What can we do with a standard Window and Desktop manager ?

I'm wondering, does anyone know if shared libraries use a shared binary image in RAM and create only state data per instance on Linux like they do on some OSs ? If that's the case then using ld.so.preload may be a way of improving load times.

[pgas]

I think that matchbox support something like one instance flag, see the terminal launcher or the xkvb launcher, only once instance of the application is launch.

Not that openbox, the windows manager used offers a bit more than what we see, try to check its homepage.

Not also that you can try to launch the matchbox panel in fluxbox, or the applet in fluxbox,
I think that all these uses the freedesktop.org standards and are more or less compatible.

What do you mean by standard wm or desktop?

[iamasmith]

What do you mean by standard wm or desktop?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=63388\"][{POST_SNAPBACK}][/a][/div]

Sorry I should have said.....

THE standard WM or desktop

...or actually realising how controversial the term 'standard' can be.....

the default WM or desktop

Actuall pgas, what you were saying about single instances of aterm doesn't hold true if you launch from the 'Other' menu. It only limits to single instance if you use taskbar launcher icons...

Perhaps this is the answer ! just create taskbar launcher icons for Firefox etc. unfortunately Silkscreen and Button launched items do seem to run multiple times.

- Andy