Re: GH replacement proposal (includes a bit of Unicode)

[Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>]

Rob Browning wrote:

>On a related note, in many cases, I suspect all the user may really
>need is a cheap way to copy some offset + size chunk of the data into
>their own buffer, especially when dealing with homogeneous uint8
>arrays.  If so, then it might make sense to provide a set of functions
>that can do that, handling whatever locking and memcpying is needed.
>
I agree. The need for the locking functions and the direct access to the 
heap data seem only to be introduced to avoid allocating memory for 
every new conversion. With Rob's suggestion, the user can provide a 
buffer beforehand and have guile simply copy chunks of string contents 
into that buffer. This is much cleaner, since it remains hidden how 
guile represents strings internally, all locking (if necessary) can be 
done by guile internally, and still the benefit is achieved that memory 
allocation is avoided. There may still remain situations where this 
approach will impose some performance penalty, but at some point we 
simply must value our own development freedom and cleanlyness of design 
over performance.

IMO, looking at the problems with the separation of memoization and 
execution, the problems with the generational garbage collector, the 
problems with the module system: If more internals of guile would have 
remained hidden from the start, allowing us to optimize stuff behind the 
scences, guile would have a much better performance today! I spend 90% 
percent of the time that I work on the separation of memoization and 
execution thinking how I can incrementally introduce my patches such 
that the big incompatible change is postponed as late as possible.

Best regards
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel