ex11 - performance issues

Shawn Pearce spearce@REDACTED
Fri Jan 16 04:41:04 CET 2004


This is surprising, yes.  But I'm sure that KDE is also doing more
X protocol work, and more work internally to figure out how to draw
the window.

I've found tests like this to be baised sometimes to the one you would
hope is faster, but isn't really.  :-)

Yes, X pays a huge performance penalty to its process communication and
context switching overheads.  This gets to be especially true when you
are dealing with a large amount of raw RGB or YUV data which you are
trying to pass through to the X server.  (Good example is many modern
'skinned' or 'themed' GUIs or an image editer like the GIMP.)  This is
why X has the shared memory extension, so the data can be passed through
shared memory buffers instead.

Of course, the shared memory buffers are only faster if the application
works directly in the shared memory buffer.  But the XVideo extension
requires shared memory as the transport to move the YUV data between
the client and the X server.

Without the shared memory, Linux sockets are actually too slow in
moving the data.  I suspect the copy_to/from_userspace functions
within the kernel itself are not nearly as fast as the user space
programs directly reading and writing the shared memory segment.  If
you think about it, it makes sense.  In the socket case, the kernel
must traverse the page tables in software.  In the shared memory case,
the CPU does it in hardware, and is heavily cached.

So if ex11 ever intends on doing heavy image throughput, it may need
the ability to setup a shared memory segment with the X server and
write to it.  Clearly something very far off from the current state of
affairs; and something easily done with a linked in driver.

Joe Armstrong <joe@REDACTED> wrote:
> 
> Brain dump 2
> 
> ex11 appears to be *faster* than kde for GUIs stuff - 
> 
> Experiment:
> 
> 	1) Start top and ex11
> 	2) click on the "show file" demo
> 	3) zap the scrollbar up and down until I get 20% CPU load
> 	   for the X server
> 	4) Note the beam CPU usage
> 
> Results:
> 1) X server CPU c. 20% 
> 2) beam CPU usage c. 6%
> 
>         5) make a shell window the same size as the ex11 text window
>         6) repeat step 3 in the shell
> 
> Results
> 
> 1) X server CPU usage c. 20%
> 2) kdeinit CPU c. 10%
> 
> Conclusions:
> 
> 	1) the X server is the bottleneck (easy to see)
> 	2) ex11 is faster than kde :-)
> 
> How can 2) be correct? I suspect the answer lies in some context switching or
> locking that occurs in the C code.
> 
>   Interestingly,  the performance  of  X  is limited  by  the host  OS
> context switching rate. So in sync mode I could do 4,500 request/sec
> on my 400 MHz Celerion but 12,000 in async mode :-)
> 
> 
>   Comments?
> 
> /Joe
>  
> 	
> 
> 

-- 
Shawn.

  Spiritual leadership should remain spiritual leadership and the temporal
  power should not become too important in any church.
  - Eleanor Roosevelt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20040115/77b2ea9d/attachment.bin>


More information about the erlang-questions mailing list