> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff Trawick > Sent: 03 July 2002 21:16
> "Bill Stoddard" <[EMAIL PROTECTED]> writes: > > > > Have either of you benchmarked with apr_poll() or are you assuming that > > > the problem exists? > > > > > > Ryan > > > > > > > > > > Sorry didn't answer you here... There definitely are extra instructions and > > function calls involved with using apr_poll() in this case. I don't know the > > exact number but I could find out. The affects of a few dozen extra > > instructions would be insignificant in overall server performance, but you > > can say that about any place in the server. Adding function call overhead > > adds up. In this case, is easy to just avoid the extra calls altogether with > > no significant loss in code readability. > > Using apr_poll() is more complex than using poll() in this situation. > We'll have to be careful not to leak storage (i.e., create/destroy a > subpool or attach the apr_pollfd_t to the apr_socket_t the first time > we need to wait_for_io_or_timeout. And since this deals with more > than just sockets we'll have to play with the interface to > wait_for_io_or_timeout. So we munge a lot of code so that we only > call poll() from one place and we're left with extra complexity and > extra pathlength. > > An implementation using apr_poll() which is more complex and less > speedy by inspection than using poll() directly is going to be > vetoed. Oh, come on guys, let's not play the veto card so early. By inspection != real performance. Numbers first. Sander 'sounding a bit more harsh than he means to'
