Closed pdcurtis closed 11 years ago
diegoxter
commented
11 years ago Wouldn't that solution actually slow down the start-up process of cinnamon? Maybe build a cache file that reads the applications in the apps directory (/usr/applications? Can't recall now, currently on a windoze box) and gets updated every few seconds?. I mean a catalogue like kupfer does.
glebihan
commented
11 years ago What's slowing down the display of the menu isn't reading the list of applications, but creating and displaying the icons for all the categories and applications. I've tried to force it to load the icons before the menu is displayed the first time, but that actually isn't as easy as one would think it would be.
strotter
commented
11 years ago I plan on creating some videos soon of Nadia 14 on both MATE and Cinnamon to demonstrate how bad this is for me. Native/VM, PC or Laptop (including 3.8ghz quad core, GTX580, etc), all combinations of both seem to produce orders of magnitude slower rendering and loading in general, latency and response times, than MATE. I was hoping to move toward Cinnamon eventually but it's still significantly slower than my Win7/OSX/MATE environments no matter what I seem to do.
I've tried theme changes and other setting changes, still slower than everything else. I should throw in equal comparison of Ubuntu to help isolate the problem.
mtwebster
commented
11 years ago Spare yourself the effort. This is an underlying problem with the technologies used in Cinnamon (and, by extension, Gnome-Shell) and is still being reviewed to see what more we can do about this. Please confine discussion to this issue, there is no need to try to resurrect old ones. We thought we had addressed it, but obviously not.
strotter
commented
11 years ago @mtwebster Thanks for the response, I ended up installing/trying Ubuntu 12.10 since my last comment having not seen yours, but you are definitely right. Ubuntu 12.10 by default is even slower than Mint/Cinnamon at this point by an obvious margin. I've profiled many other app stacks, but there must be something going on and I'm not sure how to profile it myself.
mtwebster
commented
11 years ago I've been running some tests on my laptop. It's an i7 but I've locked it down to 800mhz, userspace mode.
With stock 1.6.7, I observe MAX 1.5 second open time, first time opening after a Cinnamon restart. Note this is not hitting the menu button (or super key) IMMEDIATELY after Cinnamon fires up - there are hidden processes at work, and of course your number will be higher. Tell me how well your Windows machine runs at startup - yes you can interact with it, but barely (I use windows daily for work) - this is simply an invalid benchmark.
So, 1.5 sec max first open (approximately 5-10 seconds after Cinnamon starts to allow system to settle)
Approximately 1 second max subsequent opening.
Back to approx 1.5 seconds on opening after a delay of about 10-15 minutes.
For the OP, I think there may be something more wrong with your system - 10 seconds, with a full CPU load just shouldn't happen, no matter what the system - are you sure you're not running in Cinnamon2d mode?
I'm not trying to be argumentative here with any of you - indeed I am trying some test code to see if there can be improvement. But in getting a 'control' group set up, I simply haven't been experiencing the extreme delays reported.
Unfortunately my old Pentium M laptop is dead or I could try this on a truly slow machine :(
bwat47
commented
11 years ago I had this problem with mint 13 on my older laptop (i5-460m, 4gb ram, intel graphics, 5400rpm hdd), but after upgrading to mint 14 its fine, opens in 1-2 seconds on cold boot, and pretty much instantly on warm. Definitely pretty odd if its taking so long on hardware as powerful as strotter's. Maybe something to do with drivers?
On my current laptop (i5-3210, 8gb ram, intel graphics, 7200rpm hybrid hdd, 8gb ram) it always opens instantly even on cold boot.
pdcurtis
commented
11 years ago As a relative newcomer to Cinnamon, but long time user of various flavors of Ubuntu, who seems to have accidentally reopened a contentious issue I would firstly like to say that I believe that an Cinnamon is by far the best desktop available for modern machines and that those involved should be encouraged and congratulated.
Coming back to the problem - I have discovered that on the MSI Wind U100 that a the menu speed on a 'fresh install' of Mint is Much faster than on my existing system which is Ubuntu 12.04 based but has been updated progressively from 11.04 with a home folder going back to 9.04 or earlier which also has a lot of old WINE programs. I used a Unetbootin LiveUSB with persistence so I could get to Cinnamon 1.6 by enabling the Romeo repository. Even using a LiveUSB the menu delay was scarcely noticeable on the first call whilst it is often 10 seconds on the 'dirty' system. The differences would certainly explain why some see a major problem whilst others see it as largely cured.
The delay ratio is much greater than linear with the combined number of applications in /usr/share/applications and ~/.local/share/applications. I am on holiday with only the MSI Wind for communications so I can not afford to be too aggressive in trying to pinpoint the problem but I will try to narrow it down and report what I discover.
davinve
commented
11 years ago Hi to everyone, I'm experiencing the same problem on my netbook (eeepc 1018p). Up to 3 secs on a cold boot, then 0.5-1 sec each time. There is a fix by joequant but it didn't work for me...
http://github.com/joequant/Cinnamon/tree/menu_speedup
Hope to see some fix soon...
joequant
commented
11 years ago Hi all. Just to give you some more background on what I found.
Cinnamon generates the menus by putting all of the applications into the menu and then making them visible/invisible. I found an issue in the menu that was easy to fix that helped speed things up on my machine.
There are a few more issues in the javascript that could speed things up. In particular there is a sort of buttons that might be causing things to take lots of time. Cinnamon creates one button per application so if you have a machine with 300 applications (and that's not unreasonable for a loaded netbook), creating the buttons seems to take some time.
Ideally cinnamon may be better off loading application buttons only on display, but that would require a lot of reengineering. It might also be a good idea to see if there is any way to speed up the javascript engine or move some critical functions from javascript to C.
Also one thing that I did find since that it appears that the slowness doesn't have anything to do with graphics drivers. The other thing is that the cinnamon internals look very well written so it's a specific issue with the menu implementation.
joequant
commented
11 years ago I found another issue which might speed things up a lot.
Cinnamon currently rebuilds the menu button list each time it's activated, and it doesn't really have to.
What I think is happening is that is in applet.js:748, it calls refreshApps any time a recent file has changed. What I think will speed the application a lot is to split refreshApps into several smaller modules, and only refresh what has to be refreshed. That way refreshApps isn't called when the menu is activated.
One other thing, I'm new to javascript programming so if there are any debugging/profiling tools that could be used for this, it would be quite nice.
mtwebster
commented
11 years ago I'm going to play around with #1406 some more, wondering if I can generate the actual icons in the app system (C) and just pass them over to the menu applet, rather than having the menu applet generate them.
mtwebster
commented
11 years ago btw, in 1.4, the menu applet regenerated the buttons each time the menu was opened, and it was significantly slower, which was why we moved to the method we have now. You're right though, breaking up the refreshes would help, at least making subsequent opens more consistently fast.
pdcurtis
commented
11 years ago This is a further report on my efforts to reduce the initial and subsequent menu delays on a MSI U100 netbook 1.6Ghz Processor 1Gbyte RAM. The end results in power on demand mode are averaged stopwatch timings of 2.25 (from ~10) seconds initial menu delay and 1.35 (~2.5) seconds for subsequent openings. My reaction times need to be removed from both so a reasonable estimate is 1.6 seconds initial delay and .7 seconds subsequently. This is fast enough that you can hit the menu (super) key and immediately start typing a program you are searching for without any loss of key strokes. This has not 'pulled' any of the ongoing work as I am currently dependent on the machine for all my communications on holiday.
This has mainly been done by a brute force reductions in the number of overall application launchers in ~/.local/share/applications which had a large number of slightly modified copies of those in /usr/share/applications resulting from using Unity and an even larger number of launchers from Windows programs running under Wine (Wine Is Not an Emulator) - Windows programs have an excessive number of menu entries (10 entries for Word 2003 alone) and additional launchers seem to be created by Wine for associations with filetypes. Hiding the Wine entries using the menu editor was less effective than removing those not required to a backup folder out of the search path. This is all consistent with others input into this and other threads. A quick way to check if the delays come from user specific launchers in ~/.local/share/applications including Wine programs is to create a new user and try the menu from it.
The other source of delays are 'Settings/Preferences/Administration' entries specific to Unity (or Cinnamon) - a few of the launcher .desktop files contain OnlyShowIn=Gnome;Unity; or OnlyShowIn=Cinnamon; lines but it is inconsistent and hand crafting is required. I also note that the menu applet needs to check such entries before generating icons etc. for this to speed things up. The same goes for Categories= entries in the launcher files and although strictly not an issue for this thread it would have made my tests much easier if the menu editor had a facility to edit the whole of a launcher (.desktop) file and I will generate a Feature Request when I have thought through the mechanisms and consequences.
Redsandro
commented
11 years ago How could I have missed this before opening #1463 ?
Anyway, the initial opening of the menu definitely shows clockcycles being thrown around like tax money. This should happen anytime except when the user orders the menu to open.
The follow-up delay of Nth opening of the menu is part clockcycles and possibly part working with (drawing) the DOM. These permanent lags definitely increase when there are more applications installed.
Both of these should happen anytime, anywhere, but not during the opening of the menu. My workstation at work also has a lagging menu, although 75% of my 16 GB of RAM is free to have the menu preloaded and there is still space for two games of Doom 3 on full RAMdrive. Just saying.
joequant
commented
11 years ago Any suggestions for profiling/debugging tools. Will global.log just dump things to STDOUT?
I have a suspicion that there is some extra event that is causing an unnecessary redraw. The code is setup so that all of the menu creation should be done in the background and the only thing that cinnamon does is to popup the menu, but I'm wondering if there is some rogue event that is causing a redraw,
dalcde
commented
11 years ago global.log will dump things to looking glass (Alt-F2 lg -> errors)
mtwebster
commented
11 years ago The icons are generated asynchronously, and because of some underlying factors, aren't actually 'forced' to be drawn and allocated until needed (the menu opening), which is why there is always some delay the first time the applet is opened. I've tried 'cheating' and quickly opening and closing the menu applet in the code on startup, and that actually works, but I don't consider it a true fix - on slower machines you can actually observe it opening and closing, and it throws some warnings as well.
We are all well aware of the concerns people have regarding the menu - a great deal of work has already gone into speeding this up from 1.4 to 1.6, and it continues. I will be closing any new issues concerning this, but leaving this one open. Please keep comments reasonable and respectful.
joequant
commented
11 years ago You can go ahead and work on breaking up the recent files.
Also I found out that my fix really doesn't to much to speed up the menu. It speeds up menu generation, but that's different from menu display. There are some things that could be done to speed up the javascript, but I don't think it's the root of the problem.
Can you point me to the icon code? Maybe some more eyes will help at the problem.
Also, lots of kudos to the cinnamon developers because you guys make it nice to develop applets.
mtwebster
commented
11 years ago The call from the applet is here:
which calls to cinnamon-app.c:
https://github.com/linuxmint/Cinnamon/blob/master/src/cinnamon-app.c#L166
which in turn calls StTextureCache (files in src/st/*)
I've done some things in https://github.com/linuxmint/Cinnamon/pull/1406 to try to speed things up in cinnamon-app.c, but I don't think it's really been successful - I think the bottleneck is in StTextureCache - it may be we need to skip the Shell Toolkit entirely and go directly to clutter calls. There is a lot of inefficiency in the texture cache code.
mtwebster
commented
11 years ago I just noticed something - I had been trying to turn off menu open 'animation' but turning it off doesn't actually remove the open/close delay built-in to boxPointer.js - I'll play around with that as well - it could be the 'tweening' that occurs is being slowed down by it trying to render the animation of all those icons. (just a thought)
Redsandro
commented
11 years ago Quote from mtwebster:
The icons are generated asynchronously, and because of some underlying factors, aren't actually 'forced' to be drawn and allocated until needed (the menu opening), which is why there is always some delay the first time the applet is opened.
Could we perhaps:
.destroy_all_children() and all the new arrays)Cinnamon/Gnome3 alike only work on the most modern of video hardware anyway, we might not want to be conservative about memory and just preload the icons.
BTW, leaving some comments here and there in the code prevents comments like:
mtwebster
commented
11 years ago a) We the cinnamon team did not write a lot of the code involved here - most of the low level stuff is from gnome-shell and clutter. Bitch at them for lack of comments. Besides, I could comment the crap out of what I do and it still would not replace the true understanding gained by reading the code and following its logic. A lot of this stuff is self-evident. We comment at our discretion. What isn't needed is 20 lines of comments for every line of code.
b) Pre-generating/pre-loading icons is an obvious thing, one which, as mentioned numerous times already in this thread, has/is being attempted, but it's not quite as simple as you make it out to be, again, for reasons already explained numerous times.
Unless we're prepared to fork our own versions of clutter and gjs (which we're not at this time) we're somewhat at the mercy of some underlying, and upstream, libraries
Redsandro
commented
11 years ago If anything, I was trying to be clever, not trying to be a bitch as you put it. Granted, I should have read better. I was trying to do the smart thing and skip the boring stuff about hardware, trying to skip ahead to where code and solutions were mentioned. Apparently everything has been said before.
Thanks for summarizing the problems! Although after reading everything including the boring stuff, I don't see problems with pre-generating icons explained (numerous times). Maybe I have sexdaily. Dyslexia. Whatever.
I will wait patiently until people intuitive enough to understand these applet specific calls as self-evident fix the issues.
mtwebster
commented
11 years ago Did a few things here: https://github.com/linuxmint/Cinnamon/pull/1469
Haven't done the splitting of refreshes up yet, I can't sneak that while at work. But 1469 seems to have a decent effect.
mtwebster
commented
11 years ago Updated #1469, split refreshes out as discussed. App list will only fully refresh when installed apps change.
joequant
commented
11 years ago Much improved. Two ideas
1) in _select_category if it gets a null then there doesn't seem to be a need to call _listApplications. It should be possible to call this._displayButtons("all")
2) Would it be possible to do this trick? Set things up so that when the menu is opened that the menu immediately loads a small number of app buttons (say 20), and then puts the rest of the loading in the background. That way when the user opens the menu, he sees the menus fully populated, and doesn't know that the other buttons which aren't being displayed are being loaded in the background.
Redsandro
commented
11 years ago On my laptop, I didn't really notice change except for the first opening taking a lot longer. But this was a single boot only. I'll check it on my office desktop next week.
Does the complex nature of this and other Cinnamon applet speed related problems perhaps stem from the fact that Gnome Shell chose JS/CSS/HTML for their interface?
I recently found that the seemingly unrelated updated Facebook for Android app was a LOT faster. It had gotten a lot, a lot of complaints about speed. Then I read an article that explained the old app was based on HTML5.
Zuckerberg said that betting on HTML5 was a mistake, and the decision to use HTML5 rather than use native code made them "burn two years" (of development time).
joequant
commented
11 years ago rensandro: Does the complex nature of this and other Cinnamon applet speed related problems perhaps stem from the fact that Gnome Shell chose JS/CSS/HTML for their interface?
No it does not. The slowness has to do with way that clutter handles OpenGL icon loading. Gnome shell is built on top of clutter which handles the processing of openGL. Clutter tries to do the "smart" thing by delaying icon loading as long as possible, which unfortunately causes it to be delayed until the menus are displayed. This is why it's been such as pain to debug/fix because the problem is with low level complex, native code, and this code interacts with hardware in random ways.
rensandro: Zuckerberg said that betting on HTML5 was a mistake, and the decision to use HTML5 rather than use native code made them "burn two years" (of development time)
It's a different situation here. The fact that gnome-shell uses JS/HTML5 makes it at least possible to do debugging/tracing of the problem. If all the cinnamon code had been in native C, we'd have zero change of finding/fixing it with the limited number of people we have here. Also the root of the issue is in the low level C code. If slowness was in the Javascript, it would have been trivial to fix.
The choice to build a GUI on top of Javascript was an excellent one unfortunately, the bad decisions were:
1) Once you build on top of Javascript, It' makes it easy to extend. Unfortunately gnome itself has been hostile to people making changes to the code.
2) The JS in gnome-shell is actually quite nice to program in..... Once you figure it out.... Unfortunately, there isn't a "Gnome-shell programming for dummies" book, which you can get at the local bookstore. The programming environment would be pleasant and easy use if there were a decent instruction manual. Writing a decent instruction manual takes a lot of time and effort, and it's something I might end up doing in the coming months if no one else gets around to it.
Redsandro
commented
11 years ago Thanks for your elaborate response. Unfortunately I've heard your point marked as (1) notoriously often. It's weird. Even Linus was annoyed by Gnome not accepting his patches. I don't think it's the best policy to ignore (the majority of?) devs/users/fans. But on the other hand, however they do things, it did make Gnome the most popular DE for X out there.
(Actually I made that up, I haven't seen statistical evidence about DE popularity.)
This is problem which seems to be known, I even found videos on the internet, but it does not seem to be the subject of any open bug reports.
The problem is that there is a significant delay of 1 - 3 seconds depending on machine (over 7 seconds on my MSI U100 in power saving mode!) before the menu opens the first time after a login. The delay remains but is much reduced when the menu is reopened - this is still quite noticeable but arguably acceptable on most machines. It occurs with all the menus I have tried and is the same if called via the Super Key or the Panel Applet. For reference this is with Cinnamon 1.6.7
I have run some checks using a MSI Wind U100 Netbook with the gnome-system-monitor running and taken screen shots. I logged out and back in, started the gnome-system-monitor from a terminal then hit the Super key. In power saver mode I have seen a delay of over 10 seconds with 100% CPU use varying between the two processors ie half total capacity continuously in use for up to 10 seconds. The second time the menu is opened the usage is usually higher for a period of a couple of seconds after which the CPU usage shows little visible increase when the menu is opened. As one would expect the effects are approximately halved when not in full power mode (set using Jupiter). I have tried using top but the terminal display is frozen during the period one is waiting for the menu to display.
After a period of time which seems to quite variable without the menu being used the delay once more becomes long.
As a short term solution it would seem sensible to 'build' the menu during the cinnamon start-up period.