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
How about just giving us a profile of memory usage? I don't know
what Lisp your are using, but Allegro, for example, has a (prof:with-
profiling (:type :space) ...) that gives you a breakdown of memory
allocation by function. This would be very helpful.
While a great deal of attention has
Scribit Chris Laux dies 25/09/2007 hora 19:33:
> > Could you give a small testcase that demonstrates this?
> [...] I don't think a small test case would produce this, but that it
> is produced by a fairly large database (GBs) with >>1000 BTrees that
> was queried by >10 parallel threads.
Could you
Pierre THIERRY wrote:
>> while using Elephant I've noticed that garbage collections now take up
>> to 10 minutes with the (current model) CPU at 100% load!?
>
> Could you give a small testcase that demonstrates this?
Sorry about the late reply.
I haven't yet managed to reproduce the behaviour ou
Scribit Chris Laux dies 13/09/2007 hora 15:26:
> while using Elephant I've noticed that garbage collections now take up
> to 10 minutes with the (current model) CPU at 100% load!?
Could you give a small testcase that demonstrates this?
Curiously,
Pierre
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
Hi all,
while using Elephant I've noticed that garbage collections now take up
to 10 minutes with the (current model) CPU at 100% load!? This even
happens when I end all "client" threads and manually invoke a full GC
despite low memory use. I've never seen anything like it before. Does
anyone have
13 matches
Mail list logo
