Re: OK, what can I do about Opera's never-ending thirst for memory?!

Daniel Eckl <[email protected]> writes:

> Hi Kenny!
>
[...]
> You can't easily get rid of the 64-bit environment without going
> virtual by using vmware/Virtualbox and install a complete independent
> 32-bit system inside. But still it might be worth a try, perhaps later
> on in case we're still stuck.

Of course, this changes a lot of variables, so I'm not sure how much we
can learn from it.

> So lets first focus on the other two points. As far as I understood,
> you can reproduce this memory usage with rather low effort, so after
> some hours it starts to raise. My first try would be to eliminate the
> pages as a cause. Start with up to 5 tabs with a more text-page,
> google, forums, webmail, whatever. The standard web user scenario. Try
> to reproduce that this way. If it does not occur, then we know it's
> triggered by the gallery pages (perhaps just one of them, who knows).
> Try to add them one by one and observe. In case memory usage raises
> linear, then it would point to your thought about not releasing
> pixmaps or such. But perhaps you see a spike in raising when adding a
> special site, so you could give the devs a hint which site triggers
> that most.

Yes, this would probably be the most useful approach.

I would first try disabling java and plug-ins just to see if that's
involved somehow.  But since we don't run plug-ins in-process on linux,
it is unlikely to be the plug-ins themselves that leak memory (as long
as it is the opera process itself that grows, of course.)


> 2009/6/16 Kenneth Crudup <[email protected]>:
[...]
>> I've been running Opera for a few years now (since 2002, anyway) and
>> this is the only platform I've seen it on, but it's also the only one
>> that's:
>>
>>  - a 64-bit platform
>>  - using the NVidia closed-source drivers
>>  - using Compiz

I have a family member who has been complaining about similar behaviour
for several years.  But he's running windows.

>> Again, I'd love to have something to send the devs (map usage, the output
>> of "inspectr" (is that finally running on the Linux/64 platform) but I
>> think in my mind it's just not releasing all the pixmaps (which could be
>> related to the display driver), but that's just my wild guess.

Yes, that would be nice.  Unfortunately, I think it would be quite hard
to make a program that could properly analyze opera's memory usage.

I doubt the display driver has any significant effect on whether opera
releases pixmaps.  Of course, if the X process is using large amounts of
memory, it is possible that it is the display driver that doesn't
release pixmaps (which could be opera's fault).  A similar argument
holds for compiz (whether a program is running under compiz or not
shouldn't really change much from the program's point of view.)

>>
>> I guess I could suffer thru the "nv" driver for a while :) and see what's
>> up, but I develop on this system, too, and stuff like that might interfere
>> with work.

As long as it is the opera process that eats memory, the X driver
shouldn't matter.  It is possible that changing the driver (or running
compiz) will to some extent change the code paths taken in opera, but I
think it's unlikely to affect the problem significantly.

>> I have a AMD 64-bit system that's "headless" (i.e., I run the standard
>> Ubuntu GNOME desktop on it, but only thru XVnc server), I could maybe
>> move over one of the saved session files and run thru that, I guess.

Given that it seems to be a rather uncommon problem, I'm not sure that
would tell us much, though.  It's changing too many things at once :)

eirik

--
Opera-Linux: https://list.opera.com/mailman/listinfo/opera-linux
More lists: https://list.opera.com/mailman/listinfo/
Unsubscribe: mailto:[email protected]?subject=unsubscribe