nsFileTransport::Process consumes 2 secs out of 19 secs startup

VERIFIED FIXED in M18

Status

()

defect
P3
normal
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: dp, Assigned: warrensomebody)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

20 years ago
Function				%	#call	millisecs
-----------------------------------------------------------------
nsFileTransport::Process		100.00	 87	2068.45
 nsLocalFileSystem::Open		 49.55	 87	2068.45
 nsPipe::nsPipeOutputStream::WriteFrom	 25.10	154	1047.67
 nsLocalFileSystem::GetInputStream	 20.81	 87	 868.64

We are reading in 87 files on startup. Most of them would be chrome files or 
gif files that dont need a progress (maybe). So just avoiding stat on them 
would save us a bunch. Here is timing on nsLocalFileSystem::Open()

Function				%	#call	millisecs
-----------------------------------------------------------------
do_GetService(nsMIMEService)		51.26	87	1060.35
nsLocalFile::GetFileSize		48.55	87	1004.24

So we do 87 calls to GetFileSize which calls stat. I think the do_GetService() 
is mostly spending time on loading the dll (that is 1 sec wow).
Reporter

Updated

20 years ago
Blocks: 7152
Assignee

Comment 1

20 years ago
This is mine...
Assignee: valeski → warren
Target Milestone: M15
Reporter

Comment 2

20 years ago
Rehooking into the right dependency for startup performance.
Blocks: 7251
No longer blocks: 7152
Assignee

Comment 3

20 years ago
Another thing that nsFileTransport::Process does that is sub-optimal, is every 
time though it's look it acquires and releases it's lock. This lock is used to 
coordinate with request cancelation. This is very friendly to the canceler, but 
takes a lot more time.

The socket transport, on the other hand, only gives up its lock when it needs 
to suspend or resume (because the buffer is full or empty). We should do that 
in the file transport too.
Assignee

Comment 4

20 years ago
Moving non-essential, non-beta2 and performance-related bugs to M17.
Target Milestone: M15 → M17
Assignee

Comment 5

20 years ago
post-beta2
Target Milestone: M17 → M18
Assignee

Comment 6

19 years ago
The issue of the lock in the file transport has been addressed. It was removed a 
week or so ago. 

Eliminating GetFileSize (or making it cheaper by consolidating it with other 
stat info) should still be looked at. See bug 18048.
Assignee

Comment 7

19 years ago
P.S. GetFileSize is related to bug 42772 - eliminate StreamIO::Open
Assignee

Comment 8

19 years ago
Closing this ancient bug. I've long since removed the lock in 
nsFileTransport::Process, and I'm not sure what else we can do with the 
GetFileSize issue.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

Comment 9

19 years ago
verified
Status: RESOLVED → VERIFIED

Updated

19 years ago
No longer blocks: 7251
You need to log in before you can comment on or make changes to this bug.