Francois Piette wrote: > Because it would need to create a try/finally frame which would have an > impact on the performance given the high rate the events may be triggered > when speaking about network I/O. And it is very easy for the component user > to use a flag to detect reentrancy in his own code. > >
A try/finally frame does not have a significant impact on performance IF no exception is actually raised. I've done some tests on my 2,21Ghz AMD 64 X2: adding a "standard" frame adds about 0.00002312 milliseconds to a call. In other words, 1 millisecond every 5000 calls. I've done the measuring in a loop that ran for 100000000 (that's 100 million times so you don't need to count the zero's). > Anyway, the vast majority of message pump call within an event handler is a > result of the developper not understanding how windows is working. Those > developers add ProcessMessages call to have the screen refreshed or similar > issues. That is frequently not the correct way to do it and it give strange > results in many cases (for example when a user double-click on a simple > button instead of simple click). > > That's true. >> Besides, I'm asking about such behavior because of the way the THttpCli >> component behaves for me. If you remember one of my earlier questions, I >> had lots of problems with the component failing to connect to my HTTP >> server. Using Ethereal I determined the connection is poor (lost >> packets, duplicate ACK's) BUT the component still averages an too high >> number of failed connections. I don't think I've had 5 consecutive >> "sessions" where no connections timed-out. And I'm saying the failure >> rate is too high because I never saw such a problem using my web >> browser. Not once! And after the time out expires and the component >> "aborts" and restarts it's Get, it usually finishes very very quickly. >> So I need to ask: Is there some other obvious thing I'm missing, like a >> call to Application.ProcessMessage? What else should I be looking for. >> > > Search for all ProcessMessages and ask yourself if it is really needed. Then > remove it. Thinks about all indirect calls to ProcessMessages such as > displaying any modal dialog box or form. > All ProcessMessages calls are accounted for; None would run from within an ICS event handler. And if you must know what I'm using ProcessMessages for I'll tell you: I'm running my own ShowModal variant because the built-in one is not flexible enough. -- Cosmin Prund -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
