On 12/7/17 1:26 PM, Daniel Kozak wrote:
> This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++ counterpart.
> One example is read_one_line function:
> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57

Wow, interesting that D uses less memory with that continue new char[1] in there!

Kind of funny that he didn't just use FILE * directly, it's totally available in D :)

-Steve

Yes using FILE* directly could be the way.  But using file.rawRead is still possible. But it is better to use static array with length one. Other problem is with string.  It would make sense make it out instead of ref and change it to empty string and use RefAppender.

Dne 7. 12. 2017 9:00 odp. napsal uživatel "Steven Schveighoffer via Digitalmars-d" <digitalmars-d@puremagic.com>:

> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>
> Kind of funny that he didn't just use FILE * directly, it's totally available in D :)
>
> -Steve
>

On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>

I would have thought that it just reuses the same pointer to the GC on each loop.

Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory

Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" < digitalmars-d@puremagic.com>:

On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/7/17 1:26 PM, Daniel Kozak wrote:
>>
>> This is not about write the best D code. It is about similar code to
>> perform same. However when I looked at the D code it is not good port of
>> C/C++. He made many mistakes which make it slower than C/C++ counterpart.
>> One example is read_one_line function:
>> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
>> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
>
>
> Wow, interesting that D uses less memory with that continue new char[1] in there!
>

I would have thought that it just reuses the same pointer to the GC on each loop.

The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender

Dne 7. 12. 2017 11:33 odp. napsal uživatel "Daniel Kozak" <kozzi11@gmail.com
>:

> Yes, it reuse the same pointer. But it still a little bit slower than accessing stack memory
>
> Dne 7. 12. 2017 11:04 odp. napsal uživatel "Iain Buclaw via Digitalmars-d" <digitalmars-d@puremagic.com>:
>
> On 7 December 2017 at 20:56, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > On 12/7/17 1:26 PM, Daniel Kozak wrote:
> >>
> >> This is not about write the best D code. It is about similar code to perform same. However when I looked at the D code it is not good port of C/C++. He made many mistakes which make it slower than C/C++
> counterpart.
> >> One example is read_one_line function:
> >> C++: https://github.com/jpakkane/pkg-config/blob/cpp/parse.cpp#L60
> >> D: https://github.com/jpakkane/pkg-config/blob/d/parse.d#L57
> >
> >
> > Wow, interesting that D uses less memory with that continue new char[1]
> in
> > there!
> >
>
> I would have thought that it just reuses the same pointer to the GC on each loop.
>
>
>

On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
>

Correct.  The semantics of ~= mean that the memory is copied around to a new allocation every time (unless the array is marked assumeSafeAppend).

On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender

wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?

On 12/07/2017 03:07 PM, Iain Buclaw wrote:
> On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
>> The other slowdown is caused by concatenation. Because std::string += is
>> more simillar to std.array.(Ref)Appender
>>
> 
> Correct.  The semantics of ~= mean that the memory is copied around to
> a new allocation every time (unless the array is marked
> assumeSafeAppend).
> 

You must have meant ~, not ~= because luckily, it is assumeSafeAppend when there is just one slice. ~= is not that bad in that case:

import std.stdio;

void main() {
    int[] a;
    foreach (i; 0 .. 10) {
        a ~= i;
        writeln(a.ptr);
    }
}

7F621818D020
7F621818D020
7F621818D020
7F621818C100
7F621818C100
7F621818C100
7F621818C100
7F621818B040
7F621818B040
7F621818B040

Ali

On 12/7/17 8:11 PM, Mengu wrote:
> On Thursday, 7 December 2017 at 22:39:44 UTC, Daniel Kozak wrote:
>> The other slowdown is caused by concatenation. Because std::string += is more simillar to std.array.(Ref)Appender
> 
> wait, i thought appenders performed better than concatenation. is that not true or did i just misunderstand your post?
> 

You misunderstood. Appender is faster than ~= to a straight array, because it doesn't have to do any opaque lookups in the GC to see if it needs to reallocate -- all the information is right there.

Daniel's point was that Appender is more akin to std::string (which doesn't have the benefit of having language-defined array operaions). If the blogger used Appender, he would have had better performance.

-Steve

On 12/7/17 6:07 PM, Iain Buclaw wrote:
> On 7 December 2017 at 23:39, Daniel Kozak <kozzi11@gmail.com> wrote:
>> The other slowdown is caused by concatenation. Because std::string += is
>> more simillar to std.array.(Ref)Appender
>>
> 
> Correct.  The semantics of ~= mean that the memory is copied around to
> a new allocation every time (unless the array is marked
> assumeSafeAppend).
> 

Slightly incorrect. If an array is not marked with the append bit (or not even part of the GC), it is copied on the *first* append. However, it is copied to a new GC block that DOES have the bit set. Further appends are amortized.

-Steve