In article <cf13rk$14jn$1@digitaldaemon.com>, Juanjo =?ISO-8859-15?Q?=C1lvarez?= says...
>
>Dave wrote:
>
>
>>>Somebody with time should implement and run the "Great Language Shootout" (updated version) to find problems like that in the current DMD compiler.
>>>
>>>http://shootout.alioth.debian.org/
>>>
>>>PS: How GDC compare to DMD on array handling?
>> 
>> Where is the updated version? I've already run half the tests, thanks to a quick start from http://www.functionalfuture.com/d/
>
>The url posted is the one of the updated version.

Can't believe I missed it the first time - been a long week, TGIF.

>
>The objective would be to fix the slow parts of the language, if the native associative array is damn slow use it so maybe big W fix it :)
>

Makes total sense, but being new to the language I thought I'd ask because I don't know the history or intended use of the built-ins. For example, Java has String also, but it is not meant for heavy concatenation and the recommendation has always been to use StringBuffer (and now StringBuilder for Java1.5 when it doesn't need to be thread sychronized).

I will use the built-in AA, string and indexed arrays for everything applicable, but I bet when the comparisons come out, I'll get lots of the "hey, you should've used class X instead" type of complaints ;).

- Dave

On Sat, 7 Aug 2004 03:39:21 +0000 (UTC), Dave <Dave_member@pathlink.com> wrote:
> In article <cf13rk$14jn$1@digitaldaemon.com>, Juanjo =?ISO-8859-15?Q?=C1lvarez?=
> says...
>>
>> Dave wrote:
>>
>>
>>>> Somebody with time should implement and run the "Great Language
>>>> Shootout" (updated version) to find problems like that in the current DMD
>>>> compiler.
>>>>
>>>> http://shootout.alioth.debian.org/
>>>>
>>>> PS: How GDC compare to DMD on array handling?
>>>
>>> Where is the updated version? I've already run half the tests, thanks to a
>>> quick start from http://www.functionalfuture.com/d/
>>
>> The url posted is the one of the updated version.
>
> Can't believe I missed it the first time - been a long week, TGIF.
>
>>
>> The objective would be to fix the slow parts of the language, if the native
>> associative array is damn slow use it so maybe big W fix it :)
>>
>
> Makes total sense, but being new to the language I thought I'd ask because I
> don't know the history or intended use of the built-ins. For example, Java has
> String also, but it is not meant for heavy concatenation and the recommendation
> has always been to use StringBuffer (and now StringBuilder for Java1.5 when it
> doesn't need to be thread sychronized).

The built in D strings do not handle concatenation too well either, they reallocate each time creating only enough space for each concatentation. You can however use a little trick like so:

char[] s = "test"
int keep;

keep = s.length;
s.length = 1000;
s.length = keep;
s = s ~ "a";

to pre-allocate the space you think you might need. However there is no guarantee it won't release that memory at some point during your concatenations.

I have requested a .reserve property for strings that reserves space as the above does but with the guarantee not to release it. It also has the benefit of more intuitive and simple syntax eg.

char[] s = "test";

s.reserve = 1000;
s = s ~ "a";

So far no luck.

> I will use the built-in AA, string and indexed arrays for everything applicable,
> but I bet when the comparisons come out, I'll get lots of the "hey, you
> should've used class X instead" type of complaints ;).

To avoid that comment your intent at the top of the code.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <opscftmwn55a2sq9@digitalmars.com>, Regan Heath says...
>
>The built in D strings do not handle concatenation too well either, they reallocate each time creating only enough space for each concatentation. You can however use a little trick like so:
>
>char[] s = "test"
>int keep;
>
>keep = s.length;
>s.length = 1000;
>s.length = keep;
>s = s ~ "a";
>
>to pre-allocate the space you think you might need. However there is no guarantee it won't release that memory at some point during your concatenations.
>
>I have requested a .reserve property for strings that reserves space as the above does but with the guarantee not to release it. It also has the benefit of more intuitive and simple syntax eg.
>
>char[] s = "test";
>
>s.reserve = 1000;
>s = s ~ "a";
>

If 'reserve' is added, another suggestion could be to preemptively expand the buffer as the string grows from concatenation, to lower the copying/reallocations. I believe most C++ std::string implementations do this.

Maybe for most situations, the programmer would be able to avoid using string.reserve and performance would be better for the times it is tough to make a good guess at the size at runtime.

Maybe this is how OutBuffer currently works as well.

Dave wrote:

> Maybe for most situations, the programmer would be able to avoid using string.reserve and performance would be better for the times it is tough to make a good guess at the size at runtime.

An algorithm that I've find good enough for most situations and simple to code is to double the reserved size of the string every time it gets out of space. I think that's also the way Python lists work.

Juanjo Álvarez wrote:

> Dave wrote:
> 
>> Maybe for most situations, the programmer would be able to avoid using string.reserve and performance would be better for the times it is tough to make a good guess at the size at runtime.
> 
> An algorithm that I've find good enough for most situations and simple to code is to double the reserved size of the string every time it gets out of space. I think that's also the way Python lists work.

Good idea - I've written some wicked fast C++ string classes (for, among other things, 'buffering' very large dynamically generated HTML pages) that would basically add 10% - 20% (can't remember exactly) whenever things were realloc'd. This avoided a bunch of swapping once the strings got large and the perf. difference for the smaller requirements was negligable. Pretty simple algorithm, but it worked. No special attention to alignment or anything else - just realloc a bit more than requested and perf. improved dramatically in tight loops.

I've never dug into what std::basic_string<> is doing internally, but it looks to be something along those lines rather than doubling it. And basic_string<> is as fast or faster for concatenation as anything else I've seen, including other built-in's like Borland Object Pascal.

Matthew, if you happen to read this, what do the STLSoft implementations do in these cases?

Thanks,

Dave