Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Std::string half of all allocations in the Chrome browser process

groups.google.com

Post reply on HN
Print view View original

91–100 of 170 posts

Re: Std::string half of all allocations in the Chrome browser process

#91

Post by maxlybbert »

TazeTSchnitzel wrote: post #27

One thing I've learned from PHP's internals is that using reference-counted strings and copying on write is a fantastic idea. You can save an awful lot of memory and allocations, and simplify your code.

Actually, the C++ standard string was designed to be easy to implement as a copy-on-write object. And one of the motivations for the libc++ project ( http://libcxx.llvm.org/ ) is to stop using that design (first bullet point under "Why a new C++ Standard Library for C++11?") because it's no longer the obviously best choice.

Re: Std::string half of all allocations in the Chrome browser process

#92

Post by paulhodge »

CyberDildonics wrote: post #54

I'm not even sure if I do stuff like this in prototypes. My experience has been that using a matrix/arena/pool can speed a program up that has inner loop allocations by x7. I think the average pc can do about 10,000,000 heap allocations per second, but as far as I know it causes thread locking to some degree. Don't many std::string implementations have small string optimizations? This is actually the first time I hav…

If you're interested in this topic then you should read the whole discussion in the link. There is a lot of talk about what optimizations are in play.

Re: Std::string half of all allocations in the Chrome browser process

#93

Post by im2w1l »

raverbashing wrote: post #25
ctur wrote: post #15

folly::fbstring, a drop-in replacement for std::string, is part of the folly library that we (Facebook) open sourced a while back. It allocates small strings in-line and larger strings on the heap and has optimizations for medium and large strings, too. It's proven quite effective for us, particularly when used with jemalloc, which it conspires with for more optimal memory management. We use it as std::string for our…

Yeah, and if I want to use it I need to replace std::string all around my code. I can't use it for other libraries, unless I replace and recompile them. And tomorrow a new library comes I need to replace everything again. Your effort is commendable, and I know squeezing gains are important in the case of fb, but in the end it's just locking yourself in a library that should've been a second though/built in.

If only they all implemented something like java.lang.CharSequence...

"A CharSequence is a readable sequence of char values. This interface provides uniform, read-only access to many different kinds of char sequences. "

Re: Std::string half of all allocations in the Chrome browser process

#94

Post by humanrebar »

ninkendo wrote: post #79
humanrebar wrote: post #45

The problem with std::string is that it's named wrong. It should be called std::string_buffer, because that is what it is. Its performance characteristics are closer to a std::vector than a std::array (now available since C++11). Many projects cannot copy around std::vector in good conscience. They really want a copy-on-write string, an immutable string, a rope, a reference-counted string, or an always-in-place strin…

> The problem is that std::string is not a good type to use as a parameter for various reasons. In addition to its aggressive allocation behavior, it's also fairly inflexible. What are the alternatives? I think a more specific critique is that std::string is not a good type to use as a copy parameter (ie. a non-reference, non-rvalue parameter.) It's perfectly acceptable in scenarios where you're passing it as a const…

No, it's bigger than just copy parameters. std::string, even as a const reference, only works well in these cases:

1. your users already have a std::string

2. you want to support string literals

3. you'll be converting to string in the implementation anyway

What if I have a vector? What if I have a type called SanitizedString or OracleString? What about character arrays retrieved from C ABI calls?

And even if 3. is true, you are encoding implementation details in your interface. If you need to optimize your type later to use a trie, you'll have to do extra allocations and copies after all.

My point is that interfaces should require what they need: a character sequence if they need a character sequence and a character buffer if they need a character buffer. Hence my comment about std::string being more appropriately named std::string_buffer.

Even string_ref isn't perfect because it assumes your sequence is in contiguous memory. I'm hoping developments in the C++ language and standard library comes up with a good answer to that problem, perhaps one that leverages the concepts proposals. But even a concepts-based solution will have drawbacks, such as requiring even more code to go in your header file.

Re: Std::string half of all allocations in the Chrome browser process

#95

Post by amaks »

There are many things in the standard C++ library which are named incorrectly (std::string), awkwardly (std::unordered_map) and and implemented inefficiently from the perspective of modern CPUs (same std::unordered_map, which uses linked list for the underlying hash table buckets). See the great talk on CppCon 2014 about those issues - https://www.youtube.com/watch?v=fHNmRkzxHWs.

Re: Std::string half of all allocations in the Chrome browser process

#96

Post by IvyMike »

rwmj wrote: post #82
ibebrett wrote: post #74

Earlier quoted context omitted.

what experience do you have with writing c++? what is the last large project you completed with it? i'm not a huge fan of c++, but it has been the foundation of an extremely large number of wildly successful and pervasive projects.

I have in the past written many large C++ projects. I now try to avoid it as much as possible, but the last time I programmed in C++ was just two weeks ago[1], and it reminded me how bad it was -- terrible error messages, and abysmal performance of the final program. At some point I will have to replace it because the program doesn't meet our performance requirements, and no one can tell me why[2]. (Edit: Apparently…

In #2, I'm curious why you didn't like sehe's answer?

Re: Std::string half of all allocations in the Chrome browser process

#97

Post by roel_v »

MrBuddyCasino wrote: post #83
roel_v wrote: post #37

Earlier quoted context omitted.

"Lessons learned, their strings work" Except that they don't. Either they are 'complete' but massive and thus slow, or they start as 'array of byte' and then their designers spend 10 years implementing a more 'complete' string type that is still fast enough and end up as #1 anyway. Of course the C++ way where there is no string type that everyone uses sucks too, it's just that strings are almost impossible to get 'ri…

It boggles the mind how many different ways to represent Strings there are in C++, and String handling in general is the major reason I'll never touch it (or C) with a 10 feet pole. I'm interested to hear though how the String handling in Java is broken. This is everything I have to know: - String - CharSequence - char[] / Character[] - StringBuilder Done. Finito. Strings are immutable, the GC will clean up after me.…

Hehe, ignorance truely is bliss I guess. Just ask yourself: what size is a char in Java? To unearth 90% of the problems with strings in any language, ask two things: first, what size is char? Any secondly, what is the length of a string? If you cannot talk about these things for an hour, you don't really understand how computers deal with strings.

Re: Std::string half of all allocations in the Chrome browser process

#98

Post by nostrademons »

rwmj wrote: post #82
ibebrett wrote: post #74

Earlier quoted context omitted.

what experience do you have with writing c++? what is the last large project you completed with it? i'm not a huge fan of c++, but it has been the foundation of an extremely large number of wildly successful and pervasive projects.

I have in the past written many large C++ projects. I now try to avoid it as much as possible, but the last time I programmed in C++ was just two weeks ago[1], and it reminded me how bad it was -- terrible error messages, and abysmal performance of the final program. At some point I will have to replace it because the program doesn't meet our performance requirements, and no one can tell me why[2]. (Edit: Apparently…

Clang's error messages are much better than GCC - it will even spell-correct your typos and suggest which symbol you actually wanted to type. Around 2010 Google switched to a hybrid Clang + GCC environment (the same source code would be piped to both compilers, the error messages from Clang would be piped back to the user while the object files from GCC were linked to form the final binary), and C++ developer happiness skyrocketed.

Re: Std::string half of all allocations in the Chrome browser process

#99

Post by nostrademons »

raverbashing wrote: post #25
ctur wrote: post #15

folly::fbstring, a drop-in replacement for std::string, is part of the folly library that we (Facebook) open sourced a while back. It allocates small strings in-line and larger strings on the heap and has optimizations for medium and large strings, too. It's proven quite effective for us, particularly when used with jemalloc, which it conspires with for more optimal memory management. We use it as std::string for our…

Yeah, and if I want to use it I need to replace std::string all around my code. I can't use it for other libraries, unless I replace and recompile them. And tomorrow a new library comes I need to replace everything again. Your effort is commendable, and I know squeezing gains are important in the case of fb, but in the end it's just locking yourself in a library that should've been a second though/built in.

Not necessarily - you can find the system headers on your machine and then do 'cp folly/FBString.h /usr/include/c++/4.9.1/string', and then every time you do #include it will pick up Folly's FBString. If a new version comes out, just drop it there. If you're a large corporation, just modify your build system to use your custom standard headers.

It sounds like this is what Facebook does - no Facebook code actually references FBString, it just uses std::string and Facebook's implementation of std::string is the Folly version. Google does something similar, where they replaced std::string with their own more efficient version, and everybody just uses it like a normal string.

Re: Std::string half of all allocations in the Chrome browser process

#100

Post by MrBuddyCasino »

roel_v wrote: post #97
MrBuddyCasino wrote: post #83

Earlier quoted context omitted.

It boggles the mind how many different ways to represent Strings there are in C++, and String handling in general is the major reason I'll never touch it (or C) with a 10 feet pole. I'm interested to hear though how the String handling in Java is broken. This is everything I have to know: - String - CharSequence - char[] / Character[] - StringBuilder Done. Finito. Strings are immutable, the GC will clean up after me.…

Hehe, ignorance truely is bliss I guess. Just ask yourself: what size is a char in Java? To unearth 90% of the problems with strings in any language, ask two things: first, what size is char? Any secondly, what is the length of a string? If you cannot talk about these things for an hour, you don't really understand how computers deal with strings.

Actually, no. 90% of the problems with strings in any language is somebody screwing up the character encoding, usually out of ignorance.

The fact that every object in Java has some overhead and probably needs some padding for alignment is utterly irrelevant. But since you asked:

- 8 bytes generic object overhead per String

- 4 bytes for the char[] ref

- 12 bytes for the char[] itself, if non-null, plus probably 4 bytes padding

- 12 bytes for length, offset and hash code int fields (3*4 bytes)

- and 2 bytes per character stored

So I guess 40 bytes for the empty string should be about it. Happy?

My customer's servers have usually 8Gb or RAM, 16Gb is becoming the norm. Nobody cares anymore. Maybe its important in your field, I don't know. No mine though.

So did I ever need to know this piece of trivia? No.

Did I have to fix someone else's code which was relying on the platform default encoding? Lots of times.

PP: actually in C, you get the usually security nightmares on top of the encoding stuff.

Post reply on HN