FreeLists / haiku-appserver / [haiku-appserver] accelerating app_server

[Stephan Assmus <superstippi@xxxxxx>]

Hi guys,

I have done some tests to see bottlenecks in our code. And I have had a 
little bit of an email exchange with one of the Be app_server engineers. So 
it looks like our app_server design is quite ok, though there is of course 
room for improvement.

One thing I noticed in my performance comparissons is that our 
client->server communication seems to take too much time. It takes us 
sometimes more than double the ammount of time in some cases to figure out 
that we don't need to do anything (disregarding drawing commands outside of 
the current clipping region). Our drawing implementation itself is 
absolutely fast enough, also the clipping. But the communication overhead 
is quite large. I have looked at our LinkSender implementation, but it 
looks fine to me. Our BLooper::check_lock() also seems to take too much 
time. I don't know why, it looks fast. (check_lock() is called in every 
drawing function). 

I have a test where I draw 100 individual points using StrokeLine() and 
measure the time inbetween two Sync()s. Running the program on ZETA 
produces these results:

drawing outside clipping region: 93 µsecs
with actual drawing: 213 µsecs
increase: 120 µsecs


running in the app_server test environment:

drawing outside clipping region: 205 µsecs
with actual drawing: 382 µsecs
increase: 177 µsecs

... the increase is just 57 µsecs more for the test environment, and that 
is for drawing into a bitmap and making sure a BView is invalidated 
eventually for every single dot. So the actual drawing is not the problem.

On the client side, we are looking at these numbers:

Dano: 15 µsecs
test environment: 45 µsecs

... to fire off the 100 StrokeLine commands to the server. 20 µsecs in our 
number are just the check_lock() implementation (using find_thread(NULL)). 
The rest of the additional delay seems to be just our communication 
overhead.

So the question is, I guess, does anybody have any ideas on how to cut down 
on those times?

One thing I cannot be sure of, is wether Dano actually does any 
communication with the server for out of clipping bounds drawing commands. 
After all, this is inside Draw() triggered from an invalidation, and the 
update rect is actually known on the client. Though BView does not have any 
members that indicate it does client side clipping, unless it stores the 
clipping in the "view_state" info. Doing the (pre-)clipping on the client 
side would blow up the code a lot, and adds a lot of overhead in case we 
draw something.

Well... I just felt I write this email and see if someone has some ideas. 
:-)

Best regards,
-Stephan