From: Alex M. <udo...@us...> - 2005-02-08 11:02:52
|
Hello, All! i have strange performance issues when ABCL works with sevlet -- from debugger (that is separate thread, spawned by lisp itself) function that generates html works about 4 msecs, but in servlet itself (that runs in threads spawned by web-server) it works about 100 msecs, that is not very good 8-] i believe problem is with threads -- something like if they are not initialized, variable lookup is too slow. can i do something with it? by the way, i've tried working with SQL server from ABCL -- works quite fine. so i'm going to try using it in some quite serious web-dev project (after some more stability test) -- i believe it will be faster and more pleasant to do in Common Lisp than in PHP even if i'll have to do some tools and somewhat debug implementation 8-] so far it appears to be quite stable -- better than in my previous experience with CMUCL with mod_lisp. i even tried to compile function while it's being benchmarked by two processes -- it didn't crash, and looks like became somewhat faster 8-] With best regards, Alex 'killer_storm' Mizrahi. |
From: Andras S. <as...@ma...> - 2005-02-08 13:05:37
|
On Tue, 8 Feb 2005, Alex Mizrahi wrote: > Hello, All! > > i have strange performance issues when ABCL works with sevlet -- from > debugger (that is separate thread, spawned by lisp itself) function that > generates html works about 4 msecs, but in servlet itself (that runs in > threads spawned by web-server) it works about 100 msecs, that is not very > good 8-] > i believe problem is with threads -- something like if they are not > initialized, variable lookup is too slow. can i do something with it? I can't comment on this. > > by the way, i've tried working with SQL server from ABCL -- works quite > fine. so i'm going to try using it in some quite serious web-dev project > (after some more stability test) -- i believe it will be faster and more > pleasant to do in Common Lisp than in PHP even if i'll have to do some tools > and somewhat debug implementation 8-] so far it appears to be quite > stable -- better than in my previous experience with CMUCL with mod_lisp. i > even tried to compile function while it's being benchmarked by two > processes -- it didn't crash, and looks like became somewhat faster 8-] If you do a lot of calls to Java, you might want to give http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar a try. I cleaned it up a bit a few weeks ago, so it may actually work. (This is OT, but if you get desperate, have a look at CMUCL + Portable Aserve; it's quite stable and fast. And certainly more joy than PHP.) Andras |
From: Peter G. <pe...@ar...> - 2005-02-08 13:47:40
|
On Tue, 8 Feb 2005 at 13:02:43 +0200, Alex Mizrahi wrote: > Hello, All! > > i have strange performance issues when ABCL works with sevlet -- from > debugger (that is separate thread, spawned by lisp itself) function that > generates html works about 4 msecs, but in servlet itself (that runs in > threads spawned by web-server) it works about 100 msecs, that is not very > good 8-] > i believe problem is with threads -- something like if they are not > initialized, variable lookup is too slow. can i do something with it? Hmmm... I haven't used ABCL's threads much myself, apart from slime-for-j, which is not a very demanding application. When I first implemented threads, however, my test was to run the ANSI tests (the subset of them that ABCL could handle at that time, using ABCL's custom driver program) in two threads simultaneously, and I got it to the point where running two instances in separate threads took only a little bit more than twice as long as it took to run one instance in one thread, so I don't think threading per se is a bottleneck. But I haven't tried this in a long time. (I think the tests have grown and evolved in such a way that it wouldn't work very well now, although I don't think it would necessarily be slow). In any case I doubt that threads would cause a 25x slowdown. (Maybe it's thread creation that is slow? But still, 25x...) You might want to try ABCL's poor excuse for a profiler: (prof:with-profiling () (your code here)) or, in most cases less usefully: (prof:with-profiling (:type :count-only) (your code here)) and either way, when it finishes: (prof:show-call-counts) Bear in mind that although the profiler does work with compiled code, it won't see inlined calls to built-in functions (so to speak) or calls in code compiled with (optimize speed), so take things with a grain of salt. And I have no idea how the profiler will work with multiple threads. Congratulations, you're breaking new ground! > by the way, i've tried working with SQL server from ABCL -- works quite > fine. so i'm going to try using it in some quite serious web-dev project > (after some more stability test) -- i believe it will be faster and more > pleasant to do in Common Lisp than in PHP even if i'll have to do some tools > and somewhat debug implementation 8-] so far it appears to be quite > stable -- better than in my previous experience with CMUCL with mod_lisp. i > even tried to compile function while it's being benchmarked by two > processes -- it didn't crash, and looks like became somewhat faster 8-] Cool! -Peter |