DCT: D compiler as a collection of libraries

Roman D. Boiko rb at d-coding.com
Sat May 12 20:37:16 PDT 2012


On Saturday, 12 May 2012 at 22:19:55 UTC, Timon Gehr wrote:
> On 05/12/2012 11:08 PM, Roman D. Boiko wrote:
>> On Saturday, 12 May 2012 at 20:28:34 UTC, Tobias Pankrath 
>> wrote:
>>>> 1. If a struct is a field of heap allocated object, it will 
>>>> be
>>>> allocated and garbage collected. Only if it only exists on 
>>>> stack
>>>> (i.e., in method body), GC is not used.
>>>
>>> As far as I can tell, it won't be allocated on it's own, 
>>> since it is
>>> stored in the garbage collected object as a value field. So 
>>> using a
>>> freelist would actually increase the overhead. You have to 
>>> manage the
>>> freelist and do the allocation of the containing object.
>> Sorry for confusion. In the first point I was trying to 
>> clarify that
>> using a struct doesn't mean that it is stack allocated, but 
>> that
>> statement was off-topic for the given context. Currently I 
>> consider my
>> first point to be useless, and the second one is not relevant 
>> in *my*
>> context, since I don't do many allocations of Location, as 
>> well as in a
>> majority of other contexts. As it is often the case, 
>> performance
>> optimization should be performed only when benchmarks show it 
>> is needed.
>>
>
> Well yes, but it seems to me that you are deliberately 
> complicating the design in order to make it less efficient?

Do you mean something like what I summarized from Ary:
http://forum.dlang.org/post/pggkobonzmgdwjigyaac@forum.dlang.org ?
If that is the case, could you please add your concerns to the
dedicated issue:
https://github.com/roman-d-boiko/dct/issues/15 ?

Otherwise, if by overcomplicating you meant using a free list,
I'd like to clarify that I don't plan to introduce it yet because 
I see no reason to use it in my context.

Thanks


More information about the Digitalmars-d-announce mailing list