On Mon, 21 Jan 2008 19:12:06 -0200
“Luis L.” [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:
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).
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.
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.
–
Zed A. Shaw
Grrrr, you need a Y axis Ry. What is that measuring. Hell, shoot me
the raw data and I’ll do the graph with R (since I’m curious).
The vertical axis is requests/sec (says at the top of the graph). I
don’t bother to give actual numbers because it’s only to demonstrate
the relative increase in speed. You can generate your own data with
the script in ruby_bridge/benchmark/test_camping.rb
ry
On Jan 21, 2008 8:06 PM, Zed A. Shaw [email protected] wrote:
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.
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 L.
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
On Mon, 21 Jan 2008 20:08:46 -0200
“Luis L.” [email protected] wrote:
weeks back.
Sorry Luis, but I didn’t say “Luis, you’re a bullshitter.” I said,
“That’s bullshit.” Meaning, the claim of a large performance increase
from just removing a series of if-statements isn’t worth the loss in
security and safety.
You should know by now that if I really wanted to be mean to you I’d
say it directly to you. I’m talking about the code, nobody directly or
their personalities.
–
Zed A. Shaw
thx for the pointer, I’ll change the constructor then
On Jan 21, 2008 11:53 PM, Zed A. Shaw [email protected] wrote:
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.
Sorry Luis, but I didn’t say “Luis, you’re a bullshitter.” I said,
“That’s bullshit.” Meaning, the claim of a large performance increase
from just removing a series of if-statements isn’t worth the loss in
security and safety.
I know Zed, Monday was not a good day 
(so no personal offense, just bad wording from my side).
I was thinking sending an email with this thing I discovered on thin
code, but found the opportunity to ask here (on ry thread instead).
Don’t you hate when you don’t have enough time to do all the things you
love?
You should know by now that if I really wanted to be mean to you I’d
say it directly to you. I’m talking about the code, nobody directly or
their personalities.
Yes Zed, thankfuly you wouldn’t, right? 
I’m such a nice, lovely person, you couldn’t be mean to me 
Take care man,
–
Luis L.
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
I see what you’re saying but unfortunately without numbers on the
ordinate – specifically without knowing where zero is – it’s
impossible to evaluate even the relative differences.
Oh yeah, sorry, zero is at the the bottom. yes, the graph could be
clearer… below is my data - each line is an average of multiple runs
of ab with -n 1000.
(in truth, i avoid exposing my numbers because i’m a bit embarrassed
of my ancient computer. i think if you run them on a modern computer,
these numbers will be in the thousands.)
ebb -c 1 = 113.5025
ebb -c 10 = 93.956
ebb -c 19 = 101.156
ebb -c 28 = 110.335
ebb -c 37 = 119.89
ebb -c 46 = 93.464
ebb -c 55 = 87.46
ebb -c 64 = 93.116
ebb -c 73 = 94.01
ebb -c 82 = 80.8566666666667
ebb -c 91 = 92.064
ebb -c 100 = 98.666
evented mongrel -c 1 = 80.586
evented mongrel -c 10 = 82.418
evented mongrel -c 19 = 76.1075
evented mongrel -c 28 = 82.0766666666667
evented mongrel -c 37 = 88.45
evented mongrel -c 46 = 69.486
evented mongrel -c 55 = 72.81
evented mongrel -c 64 = 67.07
evented mongrel -c 73 = 67.3566666666667
evented mongrel -c 82 = 65.74
evented mongrel -c 91 = 65.666
evented mongrel -c 100 = 64.388
thin -c 1 = 92.1575
thin -c 10 = 74.284
thin -c 19 = 76.8
thin -c 28 = 91.85
thin -c 37 = 91.55
thin -c 46 = 74.802
thin -c 55 = 74.9
thin -c 64 = 69.886
thin -c 73 = 70.2933333333333
thin -c 82 = 63.6933333333333
thin -c 91 = 70.206
thin -c 100 = 70.262
ry
On 21 Jan 2008, at 22:11, ry dahl wrote:
Grrrr, you need a Y axis Ry. What is that measuring. Hell, shoot me
the raw data and I’ll do the graph with R (since I’m curious).
The vertical axis is requests/sec (says at the top of the graph). I
don’t bother to give actual numbers because it’s only to demonstrate
the relative increase in speed. You can generate your own data with
the script in ruby_bridge/benchmark/test_camping.rb
I see what you’re saying but unfortunately without numbers on the
ordinate – specifically without knowing where zero is – it’s
impossible to evaluate even the relative differences.
Anyway, I’ll have a go and generating my own data with that script.
Thanks.
Regards,
Andy S.
For sake of completeness, can you compare it with plain mongrel?
Yes, i’ll do that in future benchmarks. The monkey patching that
swiftiply does makes it not so easy to run regular mongrel and evented
mongrel from the same script.
Speaking of future benchmarks, I will not make announcements to
mongrel-users about Ebb anymore. Instead I will post on my livejournal
under the tag ‘ebb’
http://four.livejournal.com/tag/ebb
If you would like to exclude my other livejournal dribble and only get
Ebb updates, use this feed:
http://max.kanat.us/tag-syndicate/?user=four&tag=ebb
The git repo itself also has a feed, which I will try to make
interesting
Public Git Hosting - ebb.git/rss log
I was doing the first test compatibility for mongrel back in 2006 from
a P3 800Mhz 512MB RAM computer!
but that’s what i’m running now (eep!)
ry
On Jan 22, 2008 1:00 PM, ry dahl [email protected] wrote:
I see what you’re saying but unfortunately without numbers on the
ordinate – specifically without knowing where zero is – it’s
impossible to evaluate even the relative differences.
Oh yeah, sorry, zero is at the the bottom. yes, the graph could be
clearer… below is my data - each line is an average of multiple runs
of ab with -n 1000.
Great data Ry, thanks for it.
For sake of completeness, can you compare it with plain mongrel?
(in truth, i avoid exposing my numbers because i’m a bit embarrassed
of my ancient computer. i think if you run them on a modern computer,
these numbers will be in the thousands.)
You shouldn’t!
I was doing the first test compatibility for mongrel back in 2006 from
a P3 800Mhz 512MB RAM computer!
Not mention that first version of mongrel_service was created on that
computer!
So: don’t be hard on you
–
Luis L.
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