@joequant I tested out your github version and for me there is no noticeable difference. If any, the first menu-open after booting took even longer, but that could be random.

Although I think it is clear, especially with the first and longer delay, that this is CPU- and maybe other resources related. There is a 5 second spike in CPU usage when there is a 5 second menu delay. The follow-up half second delays also spike somewhat but it is too short to measure with a simple resource applet.

It is true though that I have quite some extra programs installed. So I am curious if the people with instant menu also have the least amount of extra packages installed?

To see if this is relevant, would you Mint colleagues be so kind to post your non-default package count?

Post in one line in large/bold (for overview purposes)[yes|no] <non-automatic package-count> like so:

yes(I have a lag/delay in the menu) or no(the menu displays instant) and then the output of this command:

The fix that I put in corrects an O(N**2) search. What happens when the menu adds a new application is that it looks over the existing apps to see if there is a duplicate with a linear search so you end up with O(N**2) behavior. I replaced the search with a hash table which gives you O(N) behavior. It helped my ASUS netbook a lot.

There are probably more inefficiencies in the javascript code. One big one is that I think it's calling refreshApp too often. It really should only refresh the app buttons when there are new apps added/removed, but unfortunately, when anything changes (i.e. recent documents), it reloads all of the apps.

I don't know if the script 'launches' everytime or if it's an 'always-on' script, but it really aught to have a menu ready at all times, and instantly show it when it is activated. Any kind of updating, adding apps, checking dupes, playing secret invisible pinball games do not concern the user and should happen anywhere, anytime but not when the user wants to see the menu.

It's indeed unfortunate that a big open source project is so badly commented. I almost have a harder time understanding the Cinnamon-menu than I have with John Carmack's Doom 3 source code. At least 30% of his code is comments about how and why.

Redsandro wrote:I tested it out, but as expected by observation ((a) default style has no shadows and (b) delay seems to vary) this appears not to be the case.

I'm sorry it didn't work for you, but the suggestion was intented for davidoide, because he expressed in a previous post he has a asus eeepc 1018p. Those machines come with a GMA 3150 GPU, that are known to have some problems with GLSL.On the other hand, the shadows in a theme have nothing to do with GLSL vertex or pixel shaders, they are fully implemented in Cairo using Cogl offscreen buffers, as you can see at the source code: https://github.com/linuxmint/Cinnamon/b ... -drawing.c (just follow the st_theme_node_paint fuction to see how a Cinnamon element is painted). But the scroll-view controls (like in the scroller at Cinnamon menu) use an effect implemented by means of glsl shaders: https://github.com/linuxmint/Cinnamon/b ... iew-fade.c

I speed-read everything as possible general solutions and give feedback when they are ineffective.Didn't catch the specificness but I hope it works for davidoide.

Hi, I'ive been reading all your answers, it's very nice of you.Unfortunately I can't follow your technical hypotheses or provide any suggestions, I'm not familiar with any programming language (except matlab, but I don't think it counts....)

For what concerns my cinnamon-menu situation I'm stack with a 2-3 sec delay on boot and 0.5-1 sec lag from the second time on. If I don't open the menu for several minutes the lag becomes more noticeable, but not as much as on cold boot.I have also noticed that the scrolling of all applications in the menu is jerkely.

I'm pretty satisfied with the overall behaviour of the cinnamon-mint synergy, although as a newbie user I find annoying to see some things working very fast and others (maybe more frequently used) too slow also for a basic configuration like mine.

Yes, I did. I think that it has helped a little. At the moment I have used joequant fix and yours. The delay on cold boot I'm quite sure was higher without any fix (4-5 sec, now 2-3) while the lag in the subsequent opening is maybe reduced a little, and it's acceptable now. Instead the scrolling problem is very annoying...it's better to use the search directly

Pointedstick wrote:Is it possible that you guys who are experiencing lag are using Cinnamon themes that explicitly introduce a delay or fade the menu in slowly or something? I noticed while I was trying different themes that some were much faster than others to open the menu.

I can confirm this. In my case themes like Cinnamon or OMG has a fade effect when menu show up or when disapear. Then, I tried other themes like Gnome or Loki and menu apperars more, more faster than before.

Now I using Lki theme and menu appears quickly.

Thanks for advice.

"Practice and search the truth always, question all and believe in nothing." -aceleron/S.E. Lain"The greatness of a nation can be judged by the way with that your animals are treated" -Mahatma Gandhi

Faster themes or not, the slowness is in fact known problem that cannot seem to get fixed upstream (Shell) or downstream (Cinnamon).You either need a supercomputer or a large tolerance for lag not to notice this.

The new syntax is supposed to be js.next or ECMA6 or TC39 -- I don't think the vendors have agreed on how to count, or much else, but the name is definitely "Harmony" -- and it'll be right along, one of these years.

Agreed. Although there is also a difference between "x doesn't work well for me = x doesn't work well for anyone" and the even more annoying "x works well for me = you probably made a configuration error on your end", and I am not sure if you mean me with your statement because I have already established that "x doesn't work for me and in this case about half of the users here", but the problem has been identified and acknowledged in the bugtracker, and although I am unsure how a structural problem like that could leave half the Cinnamon population unaffected, I appreciate the attempts that are being made to fix this.

It's a well-known problem, it often receives (attempts at) fixes in the development version of Cinnamon, no one is denying it or neglecting it, no one has any problem with it not being denied or neglected....

Thank you for this thread. That’s all I can say. You most definitely have made this forum into something special. You clearly know what you are doing, you’ve covered so many bases. Thanks!