[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: Sun, 25 Apr 2004 09:54:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

Marius Vollmer wrote:

 Rob Browning <address@hidden> writes:

> 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.

 Yes, that would be a good addition. However, I'd still want to have
 the low-level functions (scm_lock_heap, scm_l_* etc.) available. You
 can use them to code the more convenient variants, but it is
 unlikely that we can provide convenience variants for all cases.

I can not understand at all, why we should introduce such a concept from the start: The non-locking related API allows users to do all they could want to do. Locking is only introduced to avoid performance problems due to memory allocation when extracting string contents. This early optimization is done at the wrong time. Before we don't even have an implementation without locking available, we don't know how much of a problem the memory allocation really is for a typical application. If it later appears that the real performance problem comes from the fact that our internal memory organization of strings is bad, we are stuck. If it later appears that the global locking introduces more performance problems than it solves, we are stuck.

Further, to really be able to rate the design of the global heap locking, I need more information about how it would be implemented: What exactly would happen at the moment one thread calls scm_lock_heap? What is the performance penalty for additional thread-switches due to the global locking? How much is it compared to the expected performance gain for the typical application? Which parts of guile are affected by introducing the global locking concept?

In general, I think the proposal is a step in the right direction. My suggestion is to start with the non-controversial stuff and provide users with an API that allows them to do everything they want, and postpone the performance optimization issues. As far as I see it, the global locking could be added later without influence on the rest of the API.

Best regards
Dirk Herrmann

reply via email to

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