On Sat, Feb 09, 2008 at 11:18:11AM +0100, Oliver Bandel wrote:
> Possibly, but I have no reason to start such an implementation,
> if the current possibilities are fast enough.
> IMHO optimization comes at the end. When things are working
> well and fast enough, optimization is wasted time.
> If the software needs optimization, it can be done then.

i though that's what you were doing ;)

> This is from a practical perspective.
> The academic perspective might be different.

i was talking on pratical perspective. i don't care about academic
research. i seen pratical problem with the 16mb limit, and also breaking
the 16mb limit means you have a faster implementation. i'ld though i
mentions it, but obviously the buffer is good enough on some usage.

> > the buffer library is actually pretty bad since it's actually just a
> > simple string.
> 
> IMHO it's differently, but I didn't looked at the code.

well i've looked at the code, and it's a string ;)
 
> > each time the buffer need to grow, the string is
> > reallocated and the previous one is copied to the new string.
> 
> Are you talking about Buffer-module or the "^"-operator?

Buffer module.

> I only do use that string to write it to a dbm-database.
> I need a certain layout of the strings, because more
> than one data-item must be stored for each key.
> It's not a complicated format, but the strings must be concated.
> I did this with "^" first, because I didn't expected
> that the string-stuff needs that much time. I thought my
> mathematical operations (statistical things) need most time,
> but my expectation was wrong. The calculations were done very fast.
> So using Bufeer-module instead of "^" for the concat's
> did bring a good performance boost.

I wasn't saying the contrary; string concatenation is really really bad
for appending obviously, since 1 string is reallocated and 2 are blitted
into this new string. obviously the buffer is much faster, because the
re-allocation doesn't happens everytimes. But the reallocation can be
avoided in another implementation, making thing even faster, depend on the
usage you have with your data.

> P.S.:
> 
> ===============================================
> # Sys.max_string_length;;
> - : int = 144115188075855863
> #
> ===============================================

you're running a 64bit version, so obviously you don't have the 16mb
limit.


-- 
Vincent Hanquez