Pierre Laplante wrote: > If I compiled a c module that embed a perl interpreter and > I benchmark this again the same module in mod_perl > > I got a big difference in favor of mod_c. >
.5 ms per request is not a big difference. It seems that way when you are a benchmarking a trivial application, but when you have a real world application, performance will typically be limited by the application logic & backend business logic, not runtime overhead of mod_perl vs. the Apache C API. So let's say your application logic will take 10ms in perl & 8 ms in C ( not much difference because you are probably talking to databases & the like for sake of argument ), then the real time a request takes is 12 ms in perl - 83.3 / sec 9.6 ms in C - 104.2 / sec The difference is still 20%, but its only 20 req/sec now, not 200. We get very similar numbers in our benchmarking. Please see the benchmarks I have published on this at: http://chamas.com/bench/ If you compare the results of the Hellow World 2000 vs. the Hello World for mod_perl and C Apache API module, you will see that the performance gap narrows the more application type work you do. This would not hold up if you were doing intensive number crunching I might add, where C would be much better in the end game, but if you are just doing web applications, you probably won't get much more performance out of a pure C implementation. Note, that if you ever have any critical sections of code in perl that need to be optimized, you can always code up that section in C using XS or the newer Inline:: modules. Further realize that if you pick an application environment like Template Toolkit, Embperl, or AxKit, you are often getting a lot of fast C under the hood anyway as those authors have already done the optimizations for you. Regards, Josh ________________________________________________________________ Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc. http://www.chamas.com NodeWorks Link Checking http://www.nodeworks.com
