Re: std::string responsible for half the allocations in chrome
On 12/20/14 11:51 AM, David Nadlinger wrote: On Saturday, 20 December 2014 at 02:14:37 UTC, Andrei Alexandrescu wrote: RCString is the solution. http://dpaste.dzfl.pl/817283c163f5 -- How would refcounting help when the issue is const vs. immutable string slices? All strings would have immutable characters. -- Andrei
Re: std::string responsible for half the allocations in chrome
On Saturday, 20 December 2014 at 02:14:37 UTC, Andrei Alexandrescu wrote: RCString is the solution. http://dpaste.dzfl.pl/817283c163f5 -- How would refcounting help when the issue is const vs. immutable string slices? David
Re: std::string responsible for half the allocations in chrome
On 12/5/14 2:17 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Dec 05, 2014 at 10:03:38PM +, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Yeah!!! String processing totally sucks in C/C++, even with clever tricks like ropes for std::string. Having said that, though, D's immutable(char)[] isn't panacea either. I've seen (well, written... *hangs head in shame*) D code that deals with const(char)[] and needs to produce string, and as a result is a bit too trigger-happy with .idup's. Causes lots of GC slowdown. It used to be that you could just grep for idup to find the problem spots, but nowadays with the to!string idiom, many of these idups could be masked behind a nice to!string (which is harmless if the source is already string, but it's not always immediately obvious at a glance). RCString is the solution. http://dpaste.dzfl.pl/817283c163f5 -- Andrei
Re: std::string responsible for half the allocations in chrome
On Saturday, 6 December 2014 at 16:32:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. At the same time, immutable means that if you do need to do any string manipulation, you need to copy the string first. I think whether immutable means more or less allocations than mutable/const is actually more dependent on application design than anything, and some applications can't afford the copying that using immutable requires.
Re: std::string responsible for half the allocations in chrome
On Sun, Dec 07, 2014 at 06:08:51PM +, Sean Kelly via Digitalmars-d wrote: On Saturday, 6 December 2014 at 16:32:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. At the same time, immutable means that if you do need to do any string manipulation, you need to copy the string first. I think whether immutable means more or less allocations than mutable/const is actually more dependent on application design than anything, and some applications can't afford the copying that using immutable requires. True, but at least if mutation is expected you could use char[] instead, which still allows cheap slicing and appending without invalidating other references to the data. In C, people pass char* everywhere without any indication of whether mutation will be expected or not (const char* is sadly not consistently used outside the stdlib... and in some places even in the stdlib). This means that whenever you're unsure, you have to strdup() yet again. D's string isn't 100% ideal though... there *are* some places in Phobos that traffick in string even where const(char)[] or char[] might make more sense. One side-effect of this is certain functions being overly eager in heap allocation because they take string but have to mutate the input, so they have to dup/idup to make the change and then return it -- again as string. The next function that has to do something else with that return value will again have to allocate all over again. T -- Живёшь только однажды.
Re: std::string responsible for half the allocations in chrome
On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ?
Re: std::string responsible for half the allocations in chrome
On Sat, Dec 06, 2014 at 05:10:09PM +0100, Joseph Rushton Wakeling via Digitalmars-d wrote: On 05/12/14 23:03, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Someone asked me the other day, and I realized I didn't have a ready answer as I'd never particularly considered it: why is it important/beneficial that the string type be immutable(char)[] ? Immutable, because then you can freely use slices as substrings without worrying that the substring you hand to function X might get modified by unrelated function Y while function X is not quite done with processing it yet. D arrays in general, because .length eliminates an entire class of performance killers, namely strlen(). :-P Plus, the GC allows you to append to strings without worrying that other references to the original string will also unwittingly get lengthened (unlike in C, where appending to a char* will cause the lengthened string to be visible via other copies of that char* too -- the solution is usually to call strdup() everywhere, which is another performance killer). T -- A linguistics professor was lecturing to his class one day. In English, he said, A double negative forms a positive. In some languages, though, such as Russian, a double negative is still a negative. However, there is no language wherein a double positive can form a negative. A voice from the back of the room piped up, Yeah, yeah.
Re: std::string responsible for half the allocations in chrome
On Saturday, 6 December 2014 at 16:10:20 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 05/12/14 23:03, deadalnix via Digitalmars-d wrote:
http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/
Looks like someone need immutable(char)[] .
Someone asked me the other day, and I realized I didn't have a
ready answer as I'd never particularly considered it: why is it
important/beneficial that the string type be immutable(char)[] ?
Because string literals must be in the read only part of the
program.
void test()
{
string s=abc;
callFunc(s);
s[0]='z'//next call to test will set a=zbc
}
Otherwise the compiler would have to create a copy everytime you
assign a string literal to variable(call .dub for you).
std::string responsible for half the allocations in chrome
http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] .
Re: std::string responsible for half the allocations in chrome
On Fri, Dec 05, 2014 at 10:03:38PM +, deadalnix via Digitalmars-d wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Yeah!!! String processing totally sucks in C/C++, even with clever tricks like ropes for std::string. Having said that, though, D's immutable(char)[] isn't panacea either. I've seen (well, written... *hangs head in shame*) D code that deals with const(char)[] and needs to produce string, and as a result is a bit too trigger-happy with .idup's. Causes lots of GC slowdown. It used to be that you could just grep for idup to find the problem spots, but nowadays with the to!string idiom, many of these idups could be masked behind a nice to!string (which is harmless if the source is already string, but it's not always immediately obvious at a glance). T -- Music critic: That's an imitation fugue!
Re: std::string responsible for half the allocations in chrome
H. S. Teoh: but nowadays with the to!string idiom, many of these idups could be masked behind a nice to!string Or an even nicer .text. Bye, bearophile
Re: std::string responsible for half the allocations in chrome
On 12/5/2014 2:03 PM, deadalnix wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Also slicing. The huge advantage of slicing is avoiding the necessity of a copy just to add the terminating 0.
Re: std::string responsible for half the allocations in chrome
On Saturday, 6 December 2014 at 00:03:17 UTC, Walter Bright wrote: On 12/5/2014 2:03 PM, deadalnix wrote: http://www.reddit.com/r/programming/comments/2ocmvb/stdstring_is_responsible_for_almost_half_of_all/ Looks like someone need immutable(char)[] . Also slicing. The huge advantage of slicing is avoiding the necessity of a copy just to add the terminating 0. That was implied in my comment.
