Skip to content

Conversation

9il
Copy link
Member

@9il 9il commented Nov 18, 2014

No description provided.

auto arr = ["Здравствуй", "Мир", "Unicode"].to!(T[]);
foreach (S; TypeTuple!(wchar,dchar))
{
auto jarr = arr.join(to!S('⧑'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be to!S(' ') not to!S('⧑')?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is special test for characters greater then 255.
Test case for ' ' is above.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 1532 (old) 1570 (new)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry... it's a font bug in my browser, it looked like a space with a different ending single quote, but actually it's a unicode character between two normal single quotes that didn't get rendered properly by my browser. Sorry for the noise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OTOH, you might want to consider using \uxxxx notation instead, in case someone doesn't have the right fonts installed to display that particular character.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

@quickfur
Copy link
Member

Also, please provide some benchmark results so that we are sure this change actually improves things, especially since the new code scans RoR twice, and it's not clear that it will actually be faster.

@9il
Copy link
Member Author

9il commented Nov 18, 2014

  1. This is not optimisation for runtime speed. This is GC optimization. Appender have internal struct in the heap. Old algo makes two allocation for forward ranges with length: one for appender and one for array in appender. The new one make only one allocation for array.
  2. Old code use scans RoR twice too (in the same cases).

@quickfur
Copy link
Member

Oh I see. It wasn't very clear from the PR title. :-)

@quickfur
Copy link
Member

But isn't Appender just a struct? Why would it allocate twice?

@9il
Copy link
Member Author

9il commented Nov 18, 2014

struct Appender(A)
{
    private struct Data
    {
        size_t capacity;
        Unqual!T[] arr;
        bool canExtend = false;
    }

    private Data* _data; // <-------------------------------

@9il 9il changed the title std.array.join optimisation std.array.join GC optimisation Nov 18, 2014
@quickfur
Copy link
Member

Hmph. Apparently that was a later change to make appender have reference semantics. :-(

Alright then, let's merge this once you fix the other stuff.

@9il
Copy link
Member Author

9il commented Nov 18, 2014

Done.

@quickfur
Copy link
Member

Thanks!

@quickfur
Copy link
Member

Auto-merge toggled on

quickfur pushed a commit that referenced this pull request Nov 18, 2014
std.array.join GC optimisation
@quickfur quickfur merged commit eb66cfa into dlang:master Nov 18, 2014
foreach(r; ror)
{
foreach(e; sepArr)
result[len++] = e;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ehm ... what if T has destructors? uninitialzedArray looks dangerous.
emplace probably is a better fit to put something into the right place in memory.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I will create PR.

@9il 9il mentioned this pull request Nov 18, 2014
@9il
Copy link
Member Author

9il commented Nov 18, 2014

Fix in PR #2747

return ret - sepLength;
}

private U trustedCast(U, V)(V v) @trusted pure nothrow { return cast(U) v; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I doubt that creating unsafe trusted functions at module scope is a good idea. In fact, I personally think it's quite an awful one. If I now read the std.array source code, I have to audit the whole module for possibly illegal uses of it. If you need it in two places, make two (probably static, to avoid allocating a closure) nested helper functions. Also helps to save on template instantiations, although that's hardly significant.

@dnadlinger
Copy link
Contributor

There are quite a few code quality issues with this PR. Please address them too.

@9il
Copy link
Member Author

9il commented Nov 19, 2014

see #2747

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants