Like Andi says, the basic flaw is that the freedesktop standard doesn't
include a program to run to update the cache, so let's fix that.

 

I would add a cache and instate the rule that whoever makes changes in
these directories needs to run the cache-update program. You may even be
able to tell the debian package system to do that for you, whenever a
package installs something there. If you give it a generic name
(xdg-update-application-cache) and symlink it to a moblin specific
implementation (e.g. moblin-update-application-cache) then the desktop
distributions can adopt it as well and make it call gnome and KDE
specific versions of the same.

 

Cheers,

Waldo

-- 

Intel Corporation - Hillsboro, Oregon

Ultra Mobility Group - Platform Software Architecture

Tel: +1 503 264 6237 - Mobile: +1 503 703-7327

________________________________

From: Spencer, Bob 
Sent: Friday, April 18, 2008 2:01 PM
To: ubuntu-mobile@lists.ubuntu.com
Cc: Li, Horace; Kleen, Andi; Bastian, Waldo; Banginwar, Rajesh
Subject: Boot time +8sec with freedesktop.org changes

 

FYI:  with the latest freedesktop.org changes, we see +8sec bootup time
increase (shortened to +6sec by Horace).  Some notes below.

Bob

 

 

________________________________

________________________________

From: Kleen, Andi 

- Checksum is difficult -- either you risk not catching a change in some
extreme cases or have to read everything again to compute it.

- Timestamp assumes your time never goes backwards and device time never
gets reset (in practice likely a dangerous assumption)

 

If you trust the time stamps or add some way to have a always monotonic
time stamp (e.g. include

the inode generation number) it's still difficult. There were some
attempts like trying to implement

inheriting mtime that flows up a directory which might work (but still
has the time stamp problem).

There were various other ideas I heard over time, but none really good.

 

Another approach was to use a fuse file system that then transparently
updates caches as files are written,

but that also has some issues.

 

The basic flaw is that the freedesktop standard doesn't include a
program to run to update the cache.

 

-Andi

 

        
________________________________


        From: Spencer, Bob 

        +7sec!

        Let's see if we can maintain freedesktop.org compliance and
leverage caching to get our time back <1sec.

        Ideas:

            - checksum of file name/sizes  in /usr/share/applications,
if no change then go to cached version

            - try to simplify / optimize loading code . Maybe we are
reading applications.menu file multiple times?  Load it once.

            - see if a smaller /etc/xdg/menus/applications.menu could
improve time

            - look into the gnome_menus code to see why it is taking so
long.  In 8sec you could start every app on the MID.  Parsing a few text
files should be trivial.

         

        Bob

         

         

        
________________________________


        From: Kleen, Andi 

        Distributions have spent a lot of effort in the past in trying
to make the freedesktop icons/menu spec boot fast and the general
conclusion was that it is hopeless with the standard without major
infrastructure changes (like serious file system/VFS support) 

        That was with spinning hard disks where seeks cost more, but i
suspect it is not that different on SSDs.

         

        The only sane way would be probably to go to some other format
for the standard applications and only support

        freedesktop for optional addons.

         

        -Andi

         

         

                
________________________________


                From: Yang, Lei A 

                Horace, 

                 

                Does the gnome-menu interface read the .desktop files
every time?

                Can we add some cache file to store the list for next
boot up? 

                We may use some mechanism that just read the .desktop
files which later than the cache file. 

                 

                 

                Thanks, 

                Lei Y

                 

                
________________________________


                From: Li, Horace 

                 

                 

                 Hi, All,

                 

                Thanks Fan & Martin for taking lots of effort to narrow
down the time consumption issue.

                 

                This afternoon, I am debugging into mobile-basic-flash
source, and the root cause is that changing the way to build up
application list increased the booting time almost 7 seconds. The main
purpose of changing the way is to get Moblin aligned to freedesktop.org
menu specification, which is part of MCT.

                 

                I added a timer in three mobile-basic-flash versions to
record elapsed time to build up applications list in different way.
Three versions are a fast one, which is 0.33, a slow one, which is the
latest 0.43, and a revised slow one, which is based on 0.43.

                 

                In Mobile-Basic-Flash 0.33, we read through each
particular desktop file, which are bundled with Mobile-Basic-Flash, by
using Glib Key-value file parser interface. While in Mobile-Basic-Flash
0.43, we read through general gnome desktop files stored in
/usr/share/applications by using gnome-menu interface and filter those
that are not intended to be showed up on Moblin. Using gnome-menu
interface will take result in a deep loop to traverse each sub menu
directories and their items.

                 

                Time elapsing differences are list below.

 

MBF 0.33

MBF 0.43

MBF0.43 Rev

 

 

building up app list (seconds)

0.873257

8.02833

6.04591

 

 

 

 

 

 

 

 

                 

                It seems like a side-effect to align to freedesktop.org
menu specification, and I am open to discuss on the solution. :-)

                 

                Thanks,

                Horace

                 

-- 
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile

Reply via email to