83843 - Frame construction dominated by AsyncOpen

Status: VERIFIED INVALID

(Core :: Networking, defect)

Description

[David Hyatt]

For pages with uncached images, I'm noticing that AsyncOpen is now utterly 
dominating frame construction.  For example, on a typical small page with only 
19 images, I have quantify data that shows 110ms spent constructing frames.  
62ms of the 110ms is spent in AsyncOpen for those 19 images.

This is unacceptably slow, so I'm filing a bug to track this issue. :)

Comment 1

[David Hyatt]

It's even worse than I implied, since LoadImage itself takes 80ms out of the 
110ms.  We get nickel and dimed for 18ms from the image memory cache getting 
and putting and from the creation of the image proxy request.

Comment 2

[David Hyatt]

This could be bogus.  Drilling down it looks like I did have the images cached, 
and time is being attributed by Quantify to a PR_Unlock in the file transport 
stuff.  That sounds like another thread doing work to me.

Let me empty my cache and try this again.

Comment 3

[Darin Fisher]

i'm anxious to hear the results from your retest.

a cache hit will incur some cost (measured in terms of disk hits) during the 
call to AsyncOpen due to the fact that it is a cache hit (we must read in the
meta data so the cache client can determine whether or not to read from the
cache or go to the network), and so it is normal for AsyncOpen to be somewhat
expensive in the event of a cache hit.

i'm not sure what we could do to eliminate this problem other than to make the
opening of a cache entry asynchronous.  but, this is a complex solution
requiring some possibley new background thread.

Comment 4

[Darin Fisher]

hyatt: any updates on this?

Comment 5

[Darin Fisher]

marking INVALID per hyatt's IRC comments:

hyatt> darin, i think that can be resolved invalid for now

Comment 6

[Bradley Baetz (:bbaetz)]

VERIFYING, although it may be worthwhile to consider why it takes so long to
read files from the cache.