Perhaps a light-weight daemon that uses inotify to listen for changes to /usr/share/applications and then update the cache. That seems easier than requiring changes to debian packages, but it would be running all the time and new packages are installed less frequently. Bob
________________________________ From: Bastian, Waldo Sent: Friday, April 18, 2008 2:21 PM To: Spencer, Bob Cc: Li, Horace; Kleen, Andi; Banginwar, Rajesh; 'ubuntu-mobile@lists.ubuntu.com' Subject: RE: Boot time +8sec with freedesktop.org changes 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