On Jan 21, 2008 8:06 PM, Zed A. Shaw <[EMAIL PROTECTED]> wrote: > On Mon, 21 Jan 2008 19:12:06 -0200 > "Luis Lavena" <[EMAIL PROTECTED]> wrote: > > > No, he removed them: > > > > http://pastie.caboo.se/141633 > > > > The ragel code will generate the http11_parser.c file, and http11.c > > file defines all the functions pointers: > <snip> > > Theory indicates that allocation happens way before the ragel code is > > getting executed, so there is no need to evaluate the conditions all > > the time, ending with a speed boost. > > That's bullshit. All of those tests are simple checks to make sure > that you aren't passing in NULL pointers (which happens when the lib is > used generally). Removing those would be a tiny little impact on the > performance since they're written in raw C. Only reason that'd speed > things up is if the compiler wasn't doing its job right (which is > possible). >
Please Zed, I'm not validating nor arguing against that decision. I just exposing that, the way I asked on #thin irc channel too a few weeks back. > It's also a performance *loss* in that a user of the library has to set > all callbacks always (or get a crash) and then every function is called > even if a user of the lib only cares about a particular piece. > That's why I was wondering, but still couldn't run my own series of tests to see how that change impact on overall performance. > Also, what's happened is now the safety checks against invalid input > are gone too. Any of those actions could fire in the parser section > and if those variables are not set then the whole program will eat it > bad. > > That's a very bad design change, and now I wish I'd gone to the dude's > demonstration so I could tell him. > > If someone wanted to optimize this just for the case where every > function is used and always set, but not lose safety then they should > change the constructor to the library to require those functions always > be set. Then you could remove the if-statements. > Good point. Still, prove of performance improvement must me shown, but there also corner cases that exposes situations like you mention. Again: I'm just exposing the situation, that's why the "in theory"... I'm not validating anything :-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
