|
From: | Dirk Herrmann |
Subject: | Re: GH replacement proposal (includes a bit of Unicode) |
Date: | Thu, 22 Apr 2004 19:58:50 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 |
Rob Browning wrote:
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.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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |