Saving image after startup forks entire opera process, MASSIVE waste of memory

Saving image after startup forks entire opera process, MASSIVE waste of memory

Is anyone else seeing this problem? (Opera 11.62, KDE 4.6.2, Kubuntu 10.10, amd64) >>

1. Have a session ready with many different tabs. Opera should take at least ~500 MiB of RAM.
2. Have KDE System Monitor or a similar tool ready.
3. After launching Opera, play a video on youtube (flash), and Ctrl+tab to another tab
4. Ctrl+tab (Opera configured to display previews in tab switcher) back to the youtube tab with playing video, right-click on an image (on of the "related videos" on the right side), select "Save image..." from the menu and then quickly observe the System Monitor.

What happens next is quite shocking: a new instance of opera, taking as much memory as the original one, appears, then disappears after closing the dialog. As someone with a (bad) habit of keeping 50+ tabs open and opera taking 1,7GiB of memory, this makes Opera quite uncomfortable to use.
I've seen this occur on many other web pages (since at least a year ago, probably more), but haven't been able to reliably replicate it. Haven't filed a bug yet - should I?
Screenshots: http://imgur.com/a/WwU7e

Have you tried other toolkits? Just wondering if it is specifically related to KDE or not. No, you don't have to install and use another desktop; there is a setting in opera:config called Dialog Toolkit which can be used to override your actual desktop.

Opera supports either KDE, GTK+ or a basic X11 toolkit. If Dialog Toolkit is set to 0 (the default), Opera will try to choose a toolkit related to the running desktop. A setting of 1 is no longer supported (it was for basic Qt, before they expanded that to actual KDE), 2 is Gtk+, 3 is KDE, and 4 is X11. Obviously if Gtk+ is not installed you can't try 2, if someone was using Gnome and didn't have KDE installed they couldn't use 3, but 4 can be used with any desktop.

If you do change it, you'll have to click on Save and then restart Opera.

This is probably done by KDE/Qt when starting the dialog, but it's not a 'huge waste of memory' as you describe. The reason is that forked processes are copy-on-write on Linux, that is, they share their memory with the forked process unless changes are made. The 'memory usage' you see in your activity monitor is not the actual amount of memory used. No changes will be made to the memory managed by Opera during the fork() and the subsequent exit from the process, so your worries don't seem to be grounded in reality.

Originally posted by AVL:

This is probably done by KDE/Qt when starting the dialog, but it's not a 'huge waste of memory' as you describe. The reason is that forked processes are copy-on-write on Linux, that is, they share their memory with the forked process unless changes are made. The 'memory usage' you see in your activity monitor is not the actual amount of memory used. No changes will be made to the memory managed by Opera during the fork() and the subsequent exit from the process, so your worries don't seem to be grounded in reality.

That's what I remember from OS classes too, but look at the very low number in the Shared column.
Either way, the thrashing of the hard drive from all the swapping as well as a few nasty OOM situations caused by this behaviour say that what you claim is not what's happening. Maybe it's not a fork() per se, but it definitely always ends up with the same amount of occupied memory. These aren't just worries, this is a reason I find myself using a competing browser more often despite its awful UI limitations.
sgunhouse - I'll get right on it.

Originally posted by sgunhouse:

Have you tried other toolkits? Just wondering if it is specifically related to KDE or not. No, you don't have to install and use another desktop; there is a setting in opera:config called Dialog Toolkit which can be used to override your actual desktop.

Opera supports either KDE, GTK+ or a basic X11 toolkit. If Dialog Toolkit is set to 0 (the default), Opera will try to choose a toolkit related to the running desktop. A setting of 1 is no longer supported (it was for basic Qt, before they expanded that to actual KDE), 2 is Gtk+, 3 is KDE, and 4 is X11. Obviously if Gtk+ is not installed you can't try 2, if someone was using Gnome and didn't have KDE installed they couldn't use 3, but 4 can be used with any desktop.

If you do change it, you'll have to click on Save and then restart Opera.

Your suspicion is correct - 2 and 4 seem to work fine (I do have GTK installed )
Also, it seems to occur with a KDE file dialog in general, as I've seen the behaviour after clicking "Save linked content as...". But only after playing around with tab switcher/flash content (which, BTW, causes the switcher to not stick and not close when Ctrl is released too quickly - this happen regardless of toolkit though). Rather tricky to reproduce.

saving any image or webpage - extreme slow( ∼ ‌30 seconds to open save dialog!!! ( on 6core cpu with 8Gb RAM)),
how i can disable forking for save dialog?
or how i can make it faster?

Change the toolkit Opera uses for dialogs.Go to opera:config#toolkit, that setting (Dialog Toolkit) chooses which toolkit Opera uses for dialogs. Default of 0 means auto-detect (presumably you're using KDE), 1 used to be Qt but is no longer used, 2 is GTK+ (if you use Gnome or XFCE or similar), 3 is KDE 4 while 4 is an internal toolkit. Choosing 4 would certainly remove the issue, I'm not certain about 2. Note that if you choose 4 Opera will no longer be aware of your desktop colors, though you'll be able to set your own colors in a section of opera:config named Interface Colors. (Of course that section is only available after choosing 4 and restarting, with any other setting it isn't meaningful and thus isn't even displayed.)