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

21–30 of 170 posts

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

#21

Post by csl »

raverbashing wrote: post #13
ajuc wrote: post #4

I've worked on a project that used all of these: std::string, QString, OString, char*. All were required by a different library that we needed. This is why a good string type should be in core language.

This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today

I guess the underlying problem is that C++ doesn't have a standardized ABI. So you get things like QStrings, etc.

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

#22

Post by MichaelGG »

simias wrote: post #3
acqq wrote: post #2

I'm old enough that I actually programmed in Turbo Pascal 3 (around 1985) which of course produced quite fast code even for the speeds of the processors then (4 MHz processors were enough for everybody, not really, but that's what we had!). That Turbo Pascal had strings that were of the limited size, but they were able to use the stack, not the heap. I still don't understand that the library string in C++ can't use t…

The C++ string library cannot bind the string to the stack frame since it doesn't know how long it's going to live. I suppose the compiler might realize that however and replace dynamic allocation by a static one but I'm not sure it's allowed to do that.

Interestingly, with Rust, the borrow checker makes it statically safe to know when you can stack alloc.

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

#23

Post by pjmlp »

raverbashing wrote: post #13
ajuc wrote: post #4

I've worked on a project that used all of these: std::string, QString, OString, char*. All were required by a different library that we needed. This is why a good string type should be in core language.

This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today

> Lessons learned, their strings work

It is worse than that, because the other alternative systems programming languages that eventually lost to C and C++ also had their string type.

Just C did not, and C++ followed along due to its compatibility story.

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

#25

Post by raverbashing »

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.

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

#26

Post by pjmlp »

csl wrote: post #21
raverbashing wrote: post #13

Earlier quoted context omitted.

This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today

I guess the underlying problem is that C++ doesn't have a standardized ABI. So you get things like QStrings, etc.

It is a standardization problem.

When C++ got introduced, it used only C standard library, so everyone wrote their own library.

C++ was already 10 years old when C++98 was a thing and compilers still needed to catch up.

You don't re-write old code just because, so this cruft shows everywhere.

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

#28

Post by MichaelCrawford »

ryandrake wrote: post #20

If you dig deeper and actually look at the source diffs, you will see that this is not about std::string being "bad" (it's not), but it's about problems with how they're using std::string. Most of the trouble was constantly converting back and forth between std::string and const char*, which needlessly produces temporary allocations. Simply moving to passing everything around as const references should help enormousl…

I beat the subject of data representation completely to death in my article "Pointers, References and Values" at:

http://www.warplife.com/tips/code/c++/memory-management/para...

One of the worst performance problems in C++ is quite commonly the creation of invisible temporaries. Sometimes they are necessary but commonly they are not.

There are specific cases where it's better to pass a value rather than a reference, for example if you have an integer in a register, and your parameter passing conventions calls for passing parameters in registers, then passing that integer as a value, rather than a reference (const or otherwise) avoids the use of memory; it also avoids the use of the memory cache, which is likely to be a more serious problem.

In general, for a C++ program to make lots of allocations of just one class isn't such a bad thing. If your default implementation is slower than you like, you might be able to speed things up considerably, as well as save memory, reduce disk paging and so on by using a custom memory allocator just for that class.

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

#29

Post by jbandela1 »

barrkel wrote: post #16
acqq wrote: post #2

I'm old enough that I actually programmed in Turbo Pascal 3 (around 1985) which of course produced quite fast code even for the speeds of the processors then (4 MHz processors were enough for everybody, not really, but that's what we had!). That Turbo Pascal had strings that were of the limited size, but they were able to use the stack, not the heap. I still don't understand that the library string in C++ can't use t…

C++'s std::string could store the first few characters inline, and only fall back to heap storage if the string is too big. I'd be surprised if some implementations don't do this already. TurboPascal's strings had a number of quirks. Maximum length was limited to 255 characters, but different string variables could declare different lengths in their types. Writing string functions that could work with any string requ…

Some implementations already do such as

* Clang LibC++ see http://stackoverflow.com/questions/21694302/what-are-the-mec...

* MSVC - see comments http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavave...

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

#30

Post by ajuc »

csl wrote: post #21
raverbashing wrote: post #13

Earlier quoted context omitted.

This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today

I guess the underlying problem is that C++ doesn't have a standardized ABI. So you get things like QStrings, etc.

It's not a matter of ABI. Even source code level compatibility would solve most of the problems. I am happy to recompile as long as I don't need to convert on every api boundary.
Post reply on HN