47795 - Linux filepicker is slow to load large directories

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Greg Roelofs]

Linux/x86/glibc on dual PII-266 with talkback nightly 2000-08-05-04-M17.

"Save Image As..." from the right-button context popup is excruciatingly slow
(roughly 8 seconds for dialog box to appear).  In addition, the box always
appears in the upper left corner of the display (regardless of previous
locations), and <return> fails to trigger the OK button--the only way to close
the dialog is with the mouse.

Save-to directory in question has 380 files--moderately large, but by no means
huge.  Saving to a small directory (two files) shows the dialog in about 0.5
seconds.

Comment 1

[Greg Roelofs]

adding "perf" keyword

Comment 2

[Peter Trudelle]

assigning to bryner, nominating for nsbeta3
How bad is this using an M18 build?

Comment 3

[Brian Ryner (not reading)]

These are two distinct things -- the speed of loading the filepicker, and it not
accepting enter as OK.  PLEASE file these types of things as separate bugs (in
this case, don't worry about the Enter->OK thing, there's another bug with a
patch attached that fixes it, which I need to check in).

Anyway, this is in no way specific to saving images.  The filepicker is just
really slow loading large directories (load time increases proportionally to
number of items in the directory).  Hyatt says we can get a substantial speedup
by converting this to use RDF, so I'm inclined to go that route.

Comment 4

[Peter Trudelle]

Going to several of my directories, the product seems to have frozen.  nsbeta3+

Comment 5

[Greg Roelofs]

Brian, sorry, but I filed six bugs that night and another in the morning, and
that was all the time I could afford on the weekend.  (The newsgroup messages
said to give it a serious shakedown, which I tried to do, but digging through a
hundred different components and trying to figure out which is relevant is very
time-consuming.)

Peter, there were no recent M18 builds at the time, but I'm downloading one
now.  I'll be able to test in the morning.

Comment 6

[Greg Roelofs]

Still dog-slow with 2000-08-07-20-M18, but per Brian's comments, that's not
surprising.

Comment 7

[Brian Ryner (not reading)]

*** Bug 38554 has been marked as a duplicate of this bug. ***

Comment 8

[Brian Ryner (not reading)]

For the interested, I have checked in the rdf filepicker changes on a branch. 
Update your xpfe/components/filepicker/res/content and
xpfe/components/filepicker/res/locale/en-US directories from
RDF_FILEPICKER_BRANCH.

I'll land this once I figure out how to handle "hidden" files (files beginning
with a dot).

Comment 9

[Brian Ryner (not reading)]

Fixed (or at least, fixed as much as we can right now).

Comment 10

[Greg Roelofs]

Verified that it's much better (3x faster?)--around 2.5 seconds for a directory
with 460+ files in it.  I guess the QA contact is supposed to actually mark
these things VERIFIED?

Does anyone know if there's an open bug for the fact that scrolling in such a
large directory doesn't draw the filenames very quickly?

Btw, thanks!

Greg

Comment 11

[timeless]

there is, you'd find it near bookmarks, history or mailnews.

Comment 12

[John Morrison]

Thanks for following up Greg. Yes, this works much more quickly now. Verified.

The "blanking" issue while scrolling is a known problem/workaround for some
painting issues. It may not get much better before nsbeta3 goes out.

[On another side note, I see that the tree scrollbar is processing a rapid 
series as clicks as double-clicks on a treeitem, and hence throwing an 
exception. I will file a separate bug on that (although the effect of this 
exception is relatively harmless). ]