[Opera-Linux] Huge memory-footprint problem SOLVED! It's GNOME's fault!

[Kenneth Crudup]

> Hmmm ... there's some 19,000 files in that directory; if GNOME's file-
> selector is leaking every time I save a file (sometimes as many as 300
> per day), that's something to consider.

> I've changed opera:config to use the Qt selector instead. Let's see
> how this does. (I didn't save many files on the session running XVnc).

Since doing this, I haven't seen Opera run more than about 2.8GB working,
and it subsequently dropped back to its quiescent value of ~1.6GB.

So Opera Devs (et al.)- the problem lay with *GNOME*! (Is it too late to
go "Ah, I knew Opera wasn't at fault!" :)

I normally save a lot of files in the course of a day- and that save dir
has a gazillion files in it; what most likely happened is the GNOME "Save"
dialog was trying to stat all those files, but not closedir() the readdir()
and/or free() up the allocated memory so *every time* I'd save a file, it'd
do this over and over, so the Opera working process would just grow larger
and larger. Believe it or not, this is an *improvement*- until they'd
dropped a fix back in May or so, that save dialog would crash Opera every
100th or so file save.

Also, I figured out what the deal is with the million file-descriptors-
NEVER use "Automatic" memory cache- if I set it there for some reason it
creates a huge amount of *on-disk* cache files that don't go away; I think
that might actually be a bug (right now I'm using a 400MB disk cache
size for testing, and with maybe some 80 tabs open I've only got 13
cache files open and 82 open FDs).

Glad to see that I'm back to sucessfully using the best browser around!

	-Kenny, off to look at the source for the file-saver dialog so
	  I can file a bug report with the GNOME folks

-- 
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809      (888) 454-8181