586353 - Shmem creation or initialization is slow

Status: RESOLVED WORKSFORME

(Core :: IPC, defect)

Description

[Matt Brubeck (:mbrubeck)]

MozGetIPCContext takes many times longer than getContext.

In the AnimatedZoom code for Fennec (see bug 584865 for details), on desktop Linux getContext takes less than 1ms while MozGetIPCContext takes between 5 and 50ms.  On a Nexus One running Android 2.2, MozGetIPCContext takes between 600 and 1500ms.

Comment 1

[Joe Drew (not getting mail)]

The only difference between GetContext and MozGetIPCContext is that we're backing it with a Shmem; this implies to me that creating Shmems is slow.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Just to make sure, you're timing a single call, not a loop?  In a loop, the fact that it's not quickstubbed and the security check could kill you (though probably not to 50ms on a desktop...).

Comment 3

[Matt Brubeck (:mbrubeck)]

(In reply to comment #2)
> Just to make sure, you're timing a single call, not a loop?

Yes, I am timing a single call, using dump(Date.now()) around this line:
http://mxr.mozilla.org/mobile-browser/source/chrome/content/AnimatedZoom.js#65

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

How large a Shmem are you creating?  Allocating a Shmem should be O(1us) on desktop, and sending the ShmemCreated message should be cheaper than that.  Initializing the Shmem might be slower than for a malloc()-allocated chunk of memory because the malloc() block might be committed already.  But, even then, we're talking maybe O(10us) for extra page faults and so forth.

I can test Shmem-only creation time in the IPDL test harness if I know the typical canvas size.

Comment 5

[Matt Brubeck (:mbrubeck)]

(In reply to comment #4)
> I can test Shmem-only creation time in the IPDL test harness if I know the
> typical canvas size.

We are creating a canvas of up to 1600x960px.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Thanks.  Hm, that's larger than I thought, but still shouldn't be worse than O(1ms) for POSIX shmem.

BUT ... let me back up a sec ... Joe, this is the "Native ID" SysV canvas that we create and then share to X11, right?  That blows my POSIX numbers out of the water.  50ms still sounds really high, but if we're causing a lot of X11 traffic (especially synchronous traffic), it's more believable.

Comment 7

[Joe Drew (not getting mail)]

It happens on Android too, though :(

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Before I forget: quick summary of what I saw on my desktop today.  Adjust up times quoted by a factor of ~10 (or more) for on-device.

 - creating (and not initializing) a "basic" IPDL shmem segment took around 8ms (!!!) because borrowed code is using mkstemp() followed by unlink() on /dev/shm to create an anonymous shmem segment.  This time is ridiculously high, and Android is going to suffer, so we should replace this code with the POSIX interface (bug 523172).
 - creating (and not initializing) a SysV IPDL shmem segment was around 75us, which seems higher than necessary but OK (might be committing and initializing to 0 under the covers, which would make more sense).
 - for MozGetIPCContext on Gtk/Ubuntu 10.4/recent NVIDIA card/NVIDIA drivers, initializing its two X11 surfaces and XSync()ing took a highly variable time, between ~70us-1000us.  That plus clearing them took up to ~3ms as measured by Date.now(), but as its resolution is 1ms that number isn't very useful.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

On android we're using ashmem rather than POSIX shmem, and on maemo we're using X surfaces, so I'm going to close this bug.  Shared surface init is now in the hands of the content process too, off the startup critical path.