On Sep 27, 2007, at 11:59 AM, Ben wrote:
You might be better off, performance
wise, doing this in a C full-text indexing system and wrapping an
interface to it.
I hadn't thought of that yet. Can you recommend any?
Elephant's use of BDB is designed for certain kind of operations and
access
> > You might be better off, performance
> > wise, doing this in a C full-text indexing system and wrapping an
> > interface to it.
>
> I hadn't thought of that yet. Can you recommend any?
lucene is good, solar is a web service packaging of it, and there is a
port for common lisp (montezuma), ruby
On Sep 27, 2007, at 11:46 AM, Chris Laux wrote:
Thanks Ian, that is some good analysis.
- If you are doing a significant amount of deserialization with
lots of
threads than you should know that each deserialization requires a
call
to (with-lock ...) to ensure that the shared pool of buffer
Thanks Ian, that is some good analysis.
> - If you are doing a significant amount of deserialization with lots of
> threads than you should know that each deserialization requires a call
> to (with-lock ...) to ensure that the shared pool of buffer streams is
> thread safe (a problem with elephant
> This was (sb-sprof:with-profiling (:mode :alloc ...) ...) ??
Yes. I exchanged the order of the two tables, as noted below. And the
line formatting is messed up at bit by email. What's wrong with it?
>> [NB: the order of the two output tables is reversed for ease of use]
SBCL version is 1.0.4
On Sep 27, 2007, at 9:39 AM, Chris Laux wrote:
How about just giving us a profile of memory usage?
The profile is at the bottom of this message, in sbcl's sb-sprof
format.
If you can't interpret the numbers let me know and I'll dig up the
explanation from the web. I'm not really sure how t
This was (sb-sprof:with-profiling (:mode :alloc ...) ...) ??
On Sep 27, 2007, at 9:39 AM, Chris Laux wrote:
How about just giving us a profile of memory usage?
The profile is at the bottom of this message, in sbcl's sb-sprof
format.
If you can't interpret the numbers let me know and I'll d
> How about just giving us a profile of memory usage?
The profile is at the bottom of this message, in sbcl's sb-sprof format.
If you can't interpret the numbers let me know and I'll dig up the
explanation from the web. I'm not really sure how to interpret the
results, and it might be buggy, becau
