[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]