Opening the dash is very slow and laggy

Reported by johnprattchristian on 2011-07-22
322
This bug affects 76 people
Affects Status Importance Assigned to Milestone
Unity
Medium
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

When I was running off a usb drive at least, opening of the app/files dash lagged a second or two behind the actual clicking of the "logo button". Just a minor thing, but was hard to ignore it

Omer Akram (om26er) wrote :

do you have by any chance 'static blur' enabled in the ccsm under unity plugin? dash opens quite instantly on an atom based 570 netbook.

Changed in unity:
status: New → Incomplete

From what I recall i think i mostly noticed it while closing, like if u open it and then try to close it (for instance, if u opened it by accident) I think it lagged a second or something.. Just something to be on the look out for

Sebastien Bacher (seb128) wrote :

Could you try if that's still an issue in precise?

Changed in unity (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Changed in unity:
importance: Undecided → Low
Sebastien Bacher (seb128) wrote :

is that specific to the first time you open it or happen every time?

Launchpad Janitor (janitor) wrote :

[Expired for unity because there has been no activity for 60 days.]

Changed in unity:
status: Incomplete → Expired
Launchpad Janitor (janitor) wrote :

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

Changed in unity (Ubuntu):
status: Incomplete → Expired
Daniel van Vugt (vanvugt) wrote :

Confirmed again by more recent duplicates.

summary: - dash should be more responsive
+ Opening the dash is very slow and laggy
Changed in unity:
status: Expired → Confirmed
Changed in unity (Ubuntu):
status: Expired → Confirmed
Changed in unity:
importance: Low → Medium
Changed in unity (Ubuntu):
importance: Low → Medium

Accessing the Unity menu, is such a common task, that this menu should be cached or pre-rendered, so that there is absolutely no noticeable lag after you hit your super key.

It literally takes 2 or 3 seconds for the Unity menu to appear after hitting the super key.

I remember back back when Windows didn't cache their start-menu. Every time you'd click it, it had to access the hard drive before it could display it. Later, they cached that into RAM, and it made start-menu navigation more instant.

When I'm launching an application, I hit my super key, and then I have to wait for the Unity menu to come up before I begin typing. This annoyance has finally grown to the point that I'm willing to write this bug-report.

All efforts should be made to cache/pre-render this menu, so that the displaying of it will be instantaneous upon user initiation!

I want my computer to always assume that my very next task is going to be to hit my super key and display the unity menu, and I want it to be geared toward making that happen instantly.

The worst part about this, is that if you hit your super key, and start typing immediately, the first two characters you type won't appear in the dash, then you have to backspace what you've typed and type it over.

This indicates to me, that the dash is acting like a program that has to launch before you interact with it.

All this should be pre-processed. I it should be running in the background, just waiting and anticipating that I'm about to hit my super key, so it can impress me that it is faster than I am!

tags: added: precise
Joonas Saarinen (jza) wrote :

My general impression about Dash is also laggy. Issues of mine are probably not related to caching, but it always takes a good 1 second for the Dash pop up after pressing the super key.

Omer Akram (om26er) wrote :

thanks for your bug report. Is that still an issue in Ubuntu 12.04? Can you please test and let us know?

Changed in unity:
status: Confirmed → Incomplete
Changed in unity (Ubuntu):
status: Confirmed → Incomplete

My previous comment were indeed regarding 12.04. This is still an issue.

Launchpad Janitor (janitor) wrote :

[Expired for Unity because there has been no activity for 60 days.]

Changed in unity:
status: Incomplete → Expired
Launchpad Janitor (janitor) wrote :

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

Changed in unity (Ubuntu):
status: Incomplete → Expired

Using 12.10 now. The dash's launch-speed seems more consistent, but it is still much slower than GNOME3's activities menu. How do they make there's so fast?

Changed in unity:
status: Expired → Confirmed
Changed in unity (Ubuntu):
status: Expired → Confirmed
Ryan (rein-hh) wrote :

I can see a noticable delay when opening the dash in Ubuntu 12.10 with active/static blur and no blur. With blur it has a delay, without blur it is instantly.

Also when the dash is maximized it takes noticably longer to open then when "windowed".

ApportVersion: 2.6.1-0ubuntu3
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
DistroCodename: quantal
DistroRelease: Ubuntu 12.10
DistroVariant: ubuntu
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
NonfreeKernelModules: wl
Package: unity 6.8.0-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Tags: quantal running-unity quantal running-unity quantal running-unity ubuntu
Uname: Linux 3.5.0-17-generic x86_64
UnreportableReason: Please work this issue through technical support channels first.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom debian-tor dip lpadmin plugdev sambashare sudo

tags: added: apport-collected quantal running-unity ubuntu

apport information

apport information

I prefer to launch full screen. It is taking 9 seconds on first load, and about 4 seconds on subsequent loads. My settings are all default except that I do prefer to launch full-screen.

My goal is to launch my applications as fast as possible. After I hit the super-key, I don't want to have to wait (at all) to begin typing (to locate an application).

I find myself typing too early (after hitting the super key), and having to backspace because the Unity dash didn't receive the first few letters I've typed.

Hugo Venhorst (yougo) wrote :

i'm no expert, but i think the dash is slower than gnome-shell because:
1) it seems the dash acts like a separate program that needs to start everytime. - Gnome-shell seems to be fully loaded in the background.
2) the dynamic content. everytime the dash opens, it needs to connect to the database and retrieve the items. it does so right from the start. when you start typing, with each letter, a new search is started to try and match. - Gnome Shell starts with a fixed list, and only searches when you type.
3) there's less animation involved. gnome-shell doesn't have previews, let alone the split-and-zoom effect. also the windows aren't displayed behind the overview, so no blur is needed, just a dark overlay. also scrolling the menu is less smooth than in unity dash.

i like the idea behind unity more than gnome-shell, but right now, i'm almost scared to open the dash. i found myself looking for an app in the launcher, notice it's not there, open a terminal instead and start the app from command line.

i'm willing to lose eyecandy if it makes the dash work again.

The dash in 12.10 is a lot slower than 12.04, i change thru ccsm the "action blur" to "no blur" that way is better but still slower than 12.04

what log do you need to work on the bug?

My system video driver is

lspci -nnk | grep -iA2 vga

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
 Subsystem: Hewlett-Packard Company Device [103c:30dd]
 Kernel driver in use: i915

Daniel van Vugt (vanvugt) wrote :

franciscoIR,

It's likely you're seeing bug 1064834. Please look at the proposed fix for that (Nux 3.10)

Hugo Venhorst (yougo) wrote :

I've done a clean wipe and install, updated, and problem still exists.

The dash opens late, populates after 20 seconds, has a type lag of 2 seconds per letter, and it's impossible to close the dash.
CPU rises to 100% of which 99% allocated to compiz, and it stays there. the system is unusable and needs to be cut off by pressing Ctrl+Alt+Backspace, switching to terminal and typing sudo killall -u <user> or even the occasional Ctrl+Alt+SysRq, REISUB.

i tried compiz --replace but i got an error saying a compositor is already active and am left without a window manager.

i made some screenshots with a terminal running top, before and after opening dash.

Hugo Venhorst (yougo) wrote :

here's the screenshot of the mess after opening dash.

is there anything i can do -a log to post, a command to run, anything?- to shed some sort of light to this?

i really don't believe only 34 people have this problem. this way ubuntu is unusable.
I really do want unity to be all that it can't be, and am not just running off to xfce or gnome-shell (which _flies_ on my machine).

Hugo Venhorst (yougo) wrote :
Eelco Herder (eelcoherder) wrote :

I confirm the above-mentioned problems with the Dash in 12.10. I turned off the blur and disabled the Amazon ads, which seems to improve performance a bit. Until at some point the Dash causes the CPU to rise. Population of the Dash takes >20 seconds, type lag of 2 seconds, occasionally the key that I happened to press at that moment causes repeated entries (e.g. "kileeeeeeeeeeeeeeeeeeee...").

IBM Thinkpad T60, 3 GB memory, dual boot with Windows 7, graphic card:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Radeon Mobility X1400 [1002:7145]
 Subsystem: Lenovo Thinkpad T60 model 2007 [17aa:2006]
 Kernel driver in use: radeon

Hugo Venhorst (yougo) wrote :

i've narrowed it down to this:

- when i have no window, or a non-maximized window open (any app):
 opening the Dash or Hud works slow and choppy, but it works. they close, and the Launcher comes back too.

- when I have a maximized window open (any app):
opening the Dash or Hud takes several seconds, they don't respond to typing and they won't close, or take incredibly long. when they do manage to close, the Launcher will not come back...

unless:
when it all gets stuck, i switch to a terminal using CTRL+ALT+[F1 to 6] wait a second and switch back with CTRL+ALT+F7, Unity has caught up to where it should be.

Conclusion: I think it has something to do with rendering unity while a window is maximized.

 I have no clue why it matters to have a window maximized or not.

Hi,
I was using 12.04 and the Dash were fine.

Now, after upgrading to 12.10 I'm experiencing this problem, and here the Dash is much more slower in maximized mode (which I normally use).
I've also noticed the increase of CPU use with the Dash opened.

Selecting 'no blur' in ccsm made some difference but is still slower than 12.04.

Since I've already have the upgraded version of nux, probably it's not bug 1064834.
Any ideas for a workaround?

Hugo Venhorst (yougo) wrote :

Hi Mauricio,

If you have the Dash in non-maximized mode, it could save some CPU, and it would allow you to click away from the dash.
using no-blur helps a bit, but for me it seems to copy the wrong piece of desktop for the dash background, so it just looks odd.

like i wrote above, somehow if there is a maximized window below the dash, the dash becomes VERY slow and sometimes won't even close.
-the trick for now is to keep all windows unmaximized when you use the Dash.

also if you have trouble closing the dash, or the HUD: it likely did get the 'close' command, but the rendering stalls.
- switching to a VT, wait a bit and witching back ( CTRL+ALT+F4, wait, CTRL+ALT+F7) it gives unity the time to render 'off-screen', and chances are the Dash caught up with the close command.

unfortunately this bug doesn't seem to be a priority, as no one has even been assigned to it since it was confirmd about half a year ago...

Freshly installed Ubuntu 12.10 on my laptop (Vaio VPCEB2S1E/W with new SSD and 8GB RAM) and I have the same issues.
Dash is damn slow! Unity (desktop switching, animations, zooming in and out, etc.) has no noticeable lag though.

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series] [1002:68c1]
 Subsystem: Sony Corporation Device [104d:9071]
 Kernel driver in use: radeon

Changed in unity:
milestone: none → 7.0.0
Severin Heiniger (severinh) wrote :

Scratch my earlier comment #16. The reason why the performance of Unity was so terrible is bug #856233. The CPU frequency of my HP EliteBook 6930p was erroneously locked at 800 MHz.

Opening the dash is still takes roughly 200 ms. Even though I would love for it to be even snappier, it is acceptable for day-to-day use. If anyone is interested, the output of unity_support_test is all green and the OpenGL renderer is Gallium 0.4 on AMD RV620.

Nizar Ben Ltaïef (nizar-ppa) wrote :

Same problem here.

Toshiba A500-1GR
Intel® Core™ i5 CPU M 430 @ 2.27GHz × 4
Ram: 3,8 Gb
Graphic card: Nvidia Geforce 330M
Resolution: 1366x768
Os: i386

The bug seems to happen when the dash is maximised and less when it's not. it takes sometime even though..
The bug just began to happen after I installed some lenses (wikipedia, cities, calc) from ppa:scopes-packagers/ppa. Don't know if it has anything to do with it but it was smooth before I installed those lenses and it didn't go back when I removed them.. Anyone have installed some lenses too?

P.S: Hope I helped. Sorry for my english, it's only my 3rd spoken language!

Look here's the bottom line test to prove the dash is too slow:

Hit the super-key, and immediately (without waiting at all) type your first name as fast as you can.

When the dash finally launches, how many of the letters (you typed) made it into the dash? How many are missing from the beginning of your name?

Even on the fastest computers I've tested, at least one character becomes missing, and the whole point of this bug report FOR ME, is to propose that NO character should be missing, EVEN ON THE SLOWEST OF COMPUTERS, if it was programmed right.

If it was programmed right, the computer would always (at least) CATCH UP with they user, BUT NOT COMPLETELY LOSE A USER INPUT, after hitting the super key!

I just test raring: Issue Unresolved.

tags: added: raring
David Callé (davidc3) wrote :

@Nizar,

installing more lenses shouldn't slow down the opening of the Dash. I currently have ~20 installed on both a "slow" and a "fast" computer and it doesn't impact the fluidity of the Dash (which is excellent on one and terrible on the other). The worst case scenario for these lenses is that they can eat more ram than they should. Nevertheless, I don't know your exact configuration, so maybe they affect your Dash in one way or the other: you can make sure they have been properly removed by looking in /usr/share/unity/lenses and see if they have left files of folders (which should have the lenses names) behind.

Stephen M. Webb (bregma) on 2013-04-04
Changed in unity:
milestone: 7.0.0 → 7.0.1
alFReD NSH (faridn-soad) wrote :

I just installed Ubuntu 13.04 and having the same expectations that is described in #35, when hit super key and type, I miss at least 1 letter. Mostly it's 2 letters. I have AMD 64bit E2-2000 APU with Radeon(tm) HD 7340 Graphics on levovo laptop. And this happens with "no blur" on the background(I wonder if dash being so slow, why "no blur" is not the default option...). The thing is that on the same laptop "Windows 7" start menu search works as fast as expected.

Exactly, if you test GNOME3, Windows7, or Windows 8, they pass the test described in comment 35. Unity does NOT.

Jan Nekvasil (jan-nekvasil) wrote :

I think I may have found something important. To see that effect too, please follow these steps:

1) Install these packages:
   sudo apt-get install compiz-plugins compizconfig-settings-manager.

2) Launch CompizConfig Settings Manager, search for "Show Repaint" plugin and switch it on. Hit the <Alt><Super>R combo.

3) Now all the areas which are redrawed with last screen update should be rendered with another transparent color overlay. Try move some windows around and open/close menus to see how it works. Notice only "damaged" regions are repainted. If the colors are changing too fast for You, try to lower the framerate in the "Composite" plugin. 10 FPS should be fine.

4) Open the Dash and watch as the whole screen (!) is repainted with every (!) update; not only during the opening fade in animation, but actually all the time until dash is closed again. In fact even a single pixel that changed in the top panel, e.g. seconds in datetime indicator or indicator-multiload forces the whole screen repaint too.

5) Hit <Alt><Super>R to again to end Your colorful bad trip.

(Raring amd64 + Mobility Radeon HD 3450/3470 + fglrx)

Andrea (sdrubish) wrote :

I'm affected too
Not even a quad-core Intel core i5+Nvidia GTX 560ti is capable of opening unity without lagging

Jan i think your post #39 is a great contribution to this, great find.

Mark Hewitt (holybladder) wrote :

Confirmed here.

Ubuntu 12.10
CPU: AMD Athlon II X4 640, quad core
Graphics: Nvidia GeForce GTS 250
RAM: 4Gb

Dash consistently takes 5-7 seconds to open the first time after boot, and 1-2 seconds to open every time after that. This has been the case since installing 12.10.

Daniel van Vugt (vanvugt) wrote :

This appears to be fixed in the latest Ubuntu 14.04 images... On an Atom N270 it used to take close on a whole minute to open the dash. Now less than one second! Can anyone else confirm?

shankao (shankao) wrote :

On 14.04 it feels definitely better, opening in around 1s. But I'm still missing some keystrokes in the search, if done too fast (see comment #35)

In order to fix this to the standard of comment #35, you'd have to change the time the dash is launched to be before the super-key is hit.

Therefore, upon login, the dash should be launched in a hidden state that doesn't capture key-inputs.

Then, hitting the super-key will immediately do the following:
(1) begins capturing key-inputs into RAM, while simultaniously:
(2) The dash is made visable
(3) After the dashes' textbox has achieves focus, cached key imputs are "placed" into the textbox
(4) Only at this point, are additional key-inputs appended directly to the focused text-box.

tags: added: trusty
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers