Opera version 9.20 is real slow on Linux! It mostly becomes visible when many tabs are open - Opera starts to take a lot of CPU time (100% for a few seconds) and it doesn't depend much on your PC configuration. Please also take a look here: http://my.opera.com/community/forums/topic.dml?id=186530 (more recent posts) I think you should bring opera-9.20 back into ~x86 and alter opera-9.10 build to include hotfix 2 for "a crash on startup caused by a recent update on several Linux distros of libX11, to patch CVE-2007-1667". Here is the info about it: http://my.opera.com/desktopteam/blog/2007/04/07/hotfix-2 And here is the build with this fix: http://snapshot.opera.com/unix/Weekly-635/
Sorry, that patch was for opera-9.20 actually.. So it looks like no way to get back to 9.10 without xorg.conf workaround..
(In reply to comment #0) > Opera version 9.20 is real slow on Linux! It mostly becomes visible when many > tabs are open - Opera starts to take a lot of CPU time (100% for a few seconds) > and it doesn't depend much on your PC configuration. Well, I run Opera on a slow system (by current standards), and I don't see any slowdown other than what is to be expected. Not that my experience counts, of course - I would mostly want to make clear that the scale of the problem is not clear to me - this is a problem that Opera, Inc. should fix. > Please also take a look here: > http://my.opera.com/community/forums/topic.dml?id=186530 > (more recent posts) > I think you should bring opera-9.20 back into ~x86 Definitely not. If you want to downgrade and never see 9.20 again, put the following line in /etc/portage/package.mask: =www-client/opera-9.20 Be careful with your $HOME/.opera directory, though. Opera doesn't support downgrading. I will leave 9.10 in the tree for a little while for adamant 9.10 users. > and alter opera-9.10 build > to include hotfix 2 for "a crash on startup caused by a recent update on > several Linux distros of libX11, to patch CVE-2007-1667". "hotfix 2" was about that new build 635. No fix for 9.10 was offered there, other than to edit xorg.conf which is what you as user are supposed to do: it is well out of the domain of the Opera ebuilds to change this for you. > And here is the build with this fix: > http://snapshot.opera.com/unix/Weekly-635/ This build was superseded by 638 which went final as Opera 9.20.
I'm running two complete ~ systems, one ~x86 and one ~amd64. On the ~amd64 system, opera 9.20 is barely usable. E.g. the "what should I do with this file" dialog pops up, I select "save as", select the path, click ok. It seems as if a new requestor pops up, I click again, Opera crashes. The same with certificate acceptance requestors etc. With any requestor I bascially have to wait 2-3 seconds until it either disappears or I can be sure it is for real. On the ~x86 system, opera 9.20 is fast as usual. As is 9.10 on the ~amd64. Judging from this, I expect the reason in some part of the emulation layer (emu-libs or kernel).
(In reply to comment #3) > I'm running two complete ~ systems, one ~x86 and one ~amd64. > On the ~amd64 system, opera 9.20 is barely usable. E.g. the "what should I do > with this file" dialog pops up, I select "save as", select the path, click ok. > It seems as if a new requestor pops up, I click again, Opera crashes. The same > with certificate acceptance requestors etc. With any requestor I bascially have > to wait 2-3 seconds until it either disappears or I can be sure it is for real. This appears to be an entirely unrelated bug. It would help if you filed a separate bug for this and then provide some more information, such as the output of `emerge --info` > On the ~x86 system, opera 9.20 is fast as usual. As is 9.10 on the ~amd64. Could you give me `emerge --info` for both systems? @Vanya: From you too, please. Are both systems current otherwise (`emerge --sync && emerge -vupDN world`)? > Judging from this, I expect the reason in some part of the emulation layer > (emu-libs or kernel). It could still be just about anything. The most important difference between 9.10 and 9.20 is Opera using "shared memory", though.
Created attachment 117788 [details] emerge --info of both systems, ~amd64 vs. ~x86 As per your request. Nothing special to see, I think.
(In reply to comment #5) > Created an attachment (id=117788) [edit] > emerge --info of both systems, ~amd64 vs. ~x86 > > As per your request. Nothing special to see, I think. Since both problems appear to be amd64 problems, I am reassigning this bug.
Have you tried to merge opera with and without "qt-static" USE flag?
> Have you tried to merge opera with and without "qt-static" USE flag? Yes, that works wonders. I'm actually sending this answer with 9.20 now :)
(In reply to comment #8) > > Have you tried to merge opera with and without "qt-static" USE flag? > Yes, that works wonders. I'm actually sending this answer with 9.20 now :) What works? USE="-qt-static" or USE="qt-static"? @amd64: should either version be masked for your arch?
(In reply to comment #9) > (In reply to comment #8) > > > Have you tried to merge opera with and without "qt-static" USE flag? > > > Yes, that works wonders. I'm actually sending this answer with 9.20 now :) > > What works? USE="-qt-static" or USE="qt-static"? > > @amd64: should either version be masked for your arch? > qt-static works better for me, I don't know if other users agree with me...
(In reply to comment #10) > > > > Have you tried to merge opera with and without "qt-static" USE flag? > > > > > Yes, that works wonders. I'm actually sending this answer with 9.20 now :) > > > > What works? USE="-qt-static" or USE="qt-static"? > > > qt-static works better for me, I don't know if other users agree with me... I do not think that qt-static solves this problem. For me it did not change anything whether it was compiled with qt-static set or not. It seems that disabling shared memory helped for me (although it is still not as fast as other versions have been), but I am not sure about it.
Now that USE=+-qt-static seems to be a possible fix, I am removing 9.10 from the tree. Please see if 9.21 fixes the problem with qt-static enabled/disabled and report back on this bug.
I don't really believe that it is AMD64 specific. On my x86 I also experience some slowness with USE=qt-static. Earlier I had those problems with X.org 6.9, which vanished with 7.1. After my holiday I updated to 7.2 and now it is slow again. So maybe a problem with an X library (though I can't tell which). Portage 2.1.2.7 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.21-gentoo-r1 i686) ================================================================= System uname: 2.6.21-gentoo-r1 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 22 May 2007 04:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache cvs digest distlocks metadata-transfer parallel-fetch sandbox sfperms sign strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE.UTF8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/emacs /usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="3dnow 3dnowext X a52 aiglx alsa artworkextra asf audiofile bash-completion beagle berkdb bidi bitmap-fonts bogofilter bootsplash branding bzip2 cairo ccache cdda cddb cdparanoia cdr cli console cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dri dts dvd dvdr dvdread dvi eds emacs emboss encode evo exif fam fat fbcon fdftk ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif glitz gnome gpm gstreamer gtk gtk2 gtkhtml hal howl iconv icq idn imagemagick imlib ipv6 isdnlog java javascript jpeg jpeg2k libg++ libnotify lirc lm_sensors mad matroska midi mikmod mime mmx mmxext mng mono mp3 mpeg mpeg2 mudflap mule nautilus ncurses nforce2 nls noaudio nocardbus novideo nowebdav nptl nptlonly nsplugin nvidia objc objc++ objc-gc offensive ogg opengl openmp pam pcre pdf perl plotutils pmu png ppds pppd prediction preview-latex print python qt3support quicktime readline reflection samba sdk session slang spell spl sse ssl svg svga t1lib tcpd theora tiff toolkit-scroll-bars totem truetype truetype-fonts type1-fonts udev unicode usb vcd videos vorbis win32codecs wmf wxwindows x86 xface xine xml xorg xosd xpm xv xvid zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" LIRC_DEVICES="atiusb" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Have you tried disabling all plugins in Opera preferences?
To all: What process is taking up the CPU while you experience this slowness? Is it opera or operapluginwrapper or something else? Is Opera taking up much RAM? Do you have View -> Fit to width enabled? And for extra points: would you think Opera runs more slowly on, say an AMD Athlon(tm) XP 2500+, than on my AMD Athlon (K7) at 700MHZ? My point being, I have seen enough discussions on "perceived inertia" of computer programs to know that this bug is heading nowhere fast. Either show some proper statistics (not feelings) along with full info on your system, i.e. emerge --info, Opera version (emerge -vp www-client/opera), what specifically takes a long time (loading pages, startup, shutdown, viewing mail, whether you use M2 at all, et cetera), or stop posting on this bug and take it to either Opera's or Gentoo's excellent forums. If you do feel you still need to post on this bug, then do it with all the info needed to _reproduce_ the slowness bug.
The update to Gnome 2.16.3 helped here on my side (x86)...so it seems to be a weird problem with Opera, X and a Gnome lib.
Closing because: - www-client/opera-9.21 is stable (bug #183404); - Opera 9.5 promises better native support for amd64[1]; - This bug has not seen any activity in nearly a month and seems outdated. [1] "There will also be 64-bit Linux/FreeBSD packages made available." http://my.opera.com/desktopteam/blog/kestrel-is-coming