202759 - File chooser uses a lot of cpu

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Gili Tzabari]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4b) Gecko/20030417
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4b) Gecko/20030417

File chooser is extremely CPU-hungry for me. When invoked it takes 3-10 seconds
to come up with cpu usage at 100%.

My system is ACP2, JFS based. 733Mhz, 512MB ram. This problem is new, builds
from about 2 months ago did not exibit this problem.

Reproducible: Always

Steps to Reproduce:
1. FILE | OPEN | D:\ <enter>
2. 10 seconds pause on JFS drive
3.

Comment 1

[Olivier Cahagne]

-> File Handling.

Comment 2

[Mike Kaply [:mkaply]]

how many files are on your D drive?

Comment 3

[Mike Kaply [:mkaply]]

There is no Open menu under file. Which open do you select?

Comment 4

[Mike Kaply [:mkaply]]

Last question. Are you using any file dialog enhancers or system utilities that
modify the file dialog.

Comment 5

[Gili Tzabari]

1) I am using FILE | OPEN FILE as a testcase
2) There are 9 files and 134 directories under my root directory (D:\)
3) I am using Styler/2 and XWorkplace/2 desktop enhancers

Comment 6

[Mike Kaply [:mkaply]]

Please disable ALL enhancers and then retry the problem.

Comment 7

[Gili Tzabari]

I am able to reproduce this problem even with all enhancers disabled. Don't you
have a JFS drive on your end you are able to reproduce this on your end as well?

Comment 8

[Mike Kaply [:mkaply]]

No, I can't reproduce this problem at all on any file system.

Comment 9

[Gili Tzabari]

Another item worth mentioning: the system is even slow when I type in the
filename I wish to save as. For example, the file dialog pops up and as I'm
typing the filename, there is massive cpu load per character I input.

Furthermore, when I try the same operation in GSView (FILE | OPEN), there is
absolutely no slowdown even though it seems the exact same file dialog is coming
up. I don't think this is enhancer-related but rather something Mozilla is doing.

Are we sure Mozilla is the default file dialog? Is it tweaking it in any way or
passing in any funky arguments?

Comment 10

[Mike Kaply [:mkaply]]

The only thing we are doing is handling one particular WM_CONTROL case:

http://lxr.mozilla.org/seamonkey/source/widget/src/os2/nsFilePicker.cpp#785

this only gets hit when you select from the dropdown. otherwise it is exactly
the same.

You can look yourself.

Comment 11

[Gili Tzabari]

If I understand it correctly, WM_CONTROL case in DirDialogProc() gets invoked
once per keypress. Looks to me like whatever you're doing for that case could
potentially slow down the entire dialog like I mentioned I'm seeing.

Is there a way we can profile this code sniplet? I'd like to simply add a timer
that tells me how long it took to go from the beginning of the case to the end,
dump that number to disk continually and then I'll try to reproduce the problem
and see if that block is the problem. Specifically if it takes > 100ms to
process that block we know we have a problem.

Comment 12

[Mike Kaply [:mkaply]]

I can certainly give you a version that doesn't do anything on WM_CONTROL to test.

but just doing an if statement on every WM_CONTROL shouldn't cause the kind of
slow down you are seeing...

Comment 13

[Gili Tzabari]

Sounds good, please ship me a version without WM_CONTROL to test

Comment 14

[Mike Kaply [:mkaply]]

Do you have Innotek's Java plugin installed?

Please remove it, and try this.

Comment 15

[knut st. osmundsen]

Yes, I've seen this problem while developing the java plugin. But, I'm unable to
reproduce it (at least not without much testing). I think for me the problem
when away without mozilla changes - since I have haven't rebuild mozilla since I
started on the plugins. However, I did recreate the mozilla profiles a lot while
testing. I'm sure I haven't seen this problem for quite a while now. Btw, I've
seen similar things with other dialogs, the 'Find in this Page' dialog for
instance, which have come and gone, and that without any java or acrobat plugins
installed. As this is basically a native OS/2 dialog I'm not sure if there is
any relation.

My first question: Is this an SMP machine?

Some suggestions to progress on this:
- Try to recreate the problem with a fresh user profile, using the default theme.
- Try remove remove all Innotek java plugins and/or acrobat plugins.
- You're running XWP, explicitly kill xwpdaemn.exe so the xwp message hooks goes
away too.

Comment 16

[Gili Tzabari]

Confirmed: Innotek's plugin is at fault.

I have the following files in my /mozilla/plugins directory:

 3-26-03  12:21          92,343           0  npj2.dll
 3-26-03  12:21           2,393           0  npj2_j11.dll
 3-26-03  12:21           2,401           0  npj2_j12.dll
 3-26-03  12:21           2,398           0  npj2_j13.dll
 3-26-03  12:21           2,400           0  npj2_j32.dll
 3-26-03  12:21           2,377           0  npj2_jpi.dll

Removing them made the problem go away.
PS: My machine is not SMP.

   Will you guys please forward this bug report to Innotek?

Comment 17

[Mike Kaply [:mkaply]]

Can you try the latest Java from Innotek? Rumor has it this might be fixed.

Comment 18

[Gili Tzabari]

Nevermind, after copying the DLLs from RC1 into my plugins directory the problem
seemed to have gone away. Closing as FIXED.