Re: Boot time +8sec with freedesktop.org changes
On Mon, Apr 21, 2008, Li, Horace wrote: what if a debian package is not an application package, which will not install desktop file to /usr/share/applications, it might also be necessary to filter those non-application package when updating cache. I don't understand the case you describe: you're saying a package doesn't ship a file in /usr/share/applications but still needs to run a cache update? Could you give an example? -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Boot time +8sec with freedesktop.org changes
I might not describe so clearly, I am saying when installing/removing a debian package that doesn't ship a file in /usr/share/applications, cache update should not be triggered. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lo?c Minier Sent: 2008年4月21日 19:56 To: ubuntu-mobile@lists.ubuntu.com Subject: Re: Boot time +8sec with freedesktop.org changes On Mon, Apr 21, 2008, Li, Horace wrote: what if a debian package is not an application package, which will not install desktop file to /usr/share/applications, it might also be necessary to filter those non-application package when updating cache. I don't understand the case you describe: you're saying a package doesn't ship a file in /usr/share/applications but still needs to run a cache update? Could you give an example? -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Boot time +8sec with freedesktop.org changes
On Mon, Apr 21, 2008, Li, Horace wrote: I might not describe so clearly, I am saying when installing/removing a debian package that doesn't ship a file in /usr/share/applications, cache update should not be triggered. It's possible to check this, but I would say it's not too bad if the trigger is run for these packages even if useless. It would only make a difference when updating only such packages and no package actually requiring a cache update (triggers are run once per dpkg run). -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
RE: Boot time +8sec with freedesktop.org changes
what if a debian package is not an application package, which will not install desktop file to /usr/share/applications, it might also be necessary to filter those non-application package when updating cache. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lo?c Minier Sent: 2008年4月19日 17:24 To: ubuntu-mobile@lists.ubuntu.com Subject: Re: Boot time +8sec with freedesktop.org changes On Fri, Apr 18, 2008, Spencer, Bob wrote: 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. dpkg in Ubuntu and soon in Debian will allow to use triggers, so any package can register interest in a tree and changes to this tree; it will only be told that the tree changed (and not what changed), but that's enough for this use case. See deb-triggers(5). HTH -- Loïc Minier -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
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
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
RE: Boot time +8sec with freedesktop.org changes
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
Re: Boot time +8sec with freedesktop.org changes
Spencer, Bob wrote: 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. Possibly a dumb question, but, perchance, does dpkg (or apt) utilize dbus to send notifications of successful package install/removal? If so, why not simply create a dbus service for that message and execute a cache update on trigger? Shane... -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Boot time +8sec with freedesktop.org changes
On Fri, Apr 18, 2008 at 5:17 PM, Shane Bryan [EMAIL PROTECTED] wrote: Spencer, Bob wrote: 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. Possibly a dumb question, but, perchance, does dpkg (or apt) utilize dbus to send notifications of successful package install/removal? If so, why not simply create a dbus service for that message and execute a cache update on trigger? Shane... If the cache updating only needs to be done after dpkg is called, why not use dpkg-divert to move the real dpkg to dpkg.real, and have the script named dpkg call dpkg.real and then update the cache? Then no daemon needs to be running at all. dpkg-divert : http://www.debian-administration.org/articles/118 -- Michael Moore - My failed attempts to draw : http://stuporglue.com/ -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
