maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Clock application is very slow to start with lots of saved alarms|
|Product:||[Maemo Official Applications] Utilities||Reporter:||viraptor|
|Bug Depends on:|
SOFTWARE VERSION: 10.2010.19-1 EXACT STEPS LEADING TO PROBLEM: 1. Go to menu 2. Start "clock" application EXPECTED OUTCOME: Starts in a reasonable time (under ~1 second probably) ACTUAL OUTCOME: Screen with icons shows up, but the icons are not clickable and the actual date and time are missing. They load after some time between 5-15 seconds. For a trivial application like clock, that's a problem. There should be no reason to wait that long just to activate the alarm. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20100501 Iceweasel/3.5.9 (like Firefox/3.5.9)
Hi, Does it use CPU in that time (e.g. you can check by running "top" in X Terminal)? I also wonder whether using strace could help to see what is happening. See http://wiki.maemo.org/Documentation/devtools/maemo5 and http://wiki.maemo.org/Documentation/devtools/maemo5/strace for more information. > EXTRA SOFTWARE INSTALLED: Can you please list them?
How can I start the application so it behaves exactly like when started via menu? I tried running "worldclock", but that leaves the program waiting with no GUI showing up at all (even if I wait for a long time). If I run "worldclock -s", it works immediately - the GUI comes up complete without the bug I described originally. Extra software: Evince, Barriosquare, BatteryGraph, File Transfers, Mauku, mBarcode, Recorder, XChat IRC, Conboy, Erming, GPXView, Hermes, mYTube, Password Safe, Vim, 3G/GSM switcher, Flashlight, Foreca Weather, Sharing plugins (YFrog, Picasa), rootsh
(In reply to comment #0) > 1. Go to menu > 2. Start "clock" application Is it also that slow when starting by clicking the system-wide status bar (with clock, battery icon etc) and click "Clock & Alarms" from the list?
(In reply to comment #3) > Is it also that slow when starting by clicking the system-wide status bar (with > clock, battery icon etc) and click "Clock & Alarms" from the list? It's a different kind of slow :) If I start it from the status bar, the clock window shows up complete with all information displayed, but... I have to wait a couple of seconds for the window to appear at all. However, when I start the app from the applications menu, it shows up immediately, but takes time to show all elements. I cannot tell if the time to wait for the window in this case is shorter or longer than the time I wait for the window to appear at all in the case above. They may be the same. This time is definitely longer than the time needed for launching some other applications which do much more than just display time / alarm though...
Here, starting Clock from the status bar takes about 8 seconds, and during this time the CPU load is around 1 (100%). IIRC it was much faster in the past. Same problem as the bug reporter when I start Clock from the application menu. And before I can use Clock, the throbber appears, showing activity.
How many Alarms do you have in the list?
(In reply to comment #6) > How many Alarms do you have in the list? About 200. If there's a simple way to empty this list, I could see if this makes a difference.
Same here - probably hundreds, the list is crazy long. I never knew they were saved when I stop them (but I guess discoverability / ui is another issue)
Following the suggestion given on http://talk.maemo.org/showthread.php?p=738068#post738068 I removed all the alarms, and now Clock starts almost immediately. The number of alarms (including hidden ones, e.g. from the update notifier) can be obtained with: grep -c cookie: /var/cache/alarmd/alarm_queue.ini
My personal opinion: Clock FAIL because of several issues combined: There are users that simply create a new alarm every day instead of reusing an existing one, plus it's possible to create more than one alarm for the same time, plus it's not possible to disable "storing" an alarm after it has been triggered.
WONTFIX according to Nokia: "When the application is launched it will show the screen shot of the application first until the complete UI or any background process for the UI is done. If the user taps on the screen shot icons nothing will happen. This issue is wont fix issue."
I disagree about the WONTFIX: Nokia answers a different question. The main problem here is not a UI problem (even though the UI could be improved), but an efficiency problem: the fact that the application is *slow* to start. Needing 8 seconds to handle 200 alarms is too much! There's an important inefficiency here.