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

11–20 of 170 posts

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

#11

Post by acqq »

tonyedgecombe wrote: post #9
acqq wrote: post #6

Earlier quoted context omitted.

I believe it would be possible to add the functionality I describe to the language if the wish of those involved existed. Even if that would mean not calling it std::string to avoid breaking the existing programs. I don't know of any current compiler that doesn't use heap when the object is made to actually call malloc (which is typically what the "new" eventually calls).

You could just use std::array

Do I have all the string functionality, nicely existing in std::string?

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

#12

Post by csl »

ExpiredLink wrote: post #5

During the 10 years I used C++ I never saw a project that used std::string as their standard string. The implementation of std::string not standardized. It may or may not have a 'small string optimization' which may not be an optimization at all. Instead of specifying a mundane immutable built-in string like in Java the C++ Standards committee decided to add even more 'advanced' features to an already overloaded lang…

The interface and behavior of std::string is standardized.

Library writers are free to implement it in any way that honors the standard. However, sometimes the requirements may lead to less than optimal implementations, I believe.

So as long as Chrome uses std::string for internal use only, there shouldn't be any problems. Using them across ABI boundaries, however, is another story.

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

#13

Post by raverbashing »

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

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

#14

Post by csl »

vegancap wrote: post #7

I literally started programming in C++ this week and I figured the over-use of std::string couldn't be a good thing hehe

It always depends on your needs.

Before you start avoiding std::string, note that the article said that one of the problems was that they went from std::string to C-strings and then allocated a new std::string. This often happens when you use both kind of strings in your code. The takeaway is to stick either to C strings or use std::strings with reference passing, dropping down to c_str() when needed.

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

#15

Post by ctur »

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 C++ applications and libraries, completely replacing std::string both for our own code and third-party code.

https://github.com/facebook/folly/blob/master/folly/docs/FBS...

In addition, it is worth noting folly::StringPiece (from folly/Range.h), which is generally a better interface for working with in-memory ranges of bytes. Hardly a new idea (it's inspired by similar libraries, such as in re2), but it permeates the APIs of many of our larger C++ systems, and folly itself, and often avoids passing std::string objects around at all.

Finally, there is also folly::fbvector, which offers similar improvements over std::vector.

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

#16

Post by barrkel »

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 required using the OpenString type[1], which passed the string by reference instead of by value, with pseudo-const semantics (the parameter couldn't be passed as a var parameter elsewhere). Using the default String type meant allocating 256 bytes for every string variable. You'd want to pass it by reference (with 'var', and later using 'const') to avoid the extra copying. {$P+} in later versions made string-typed parameters openstring by default[2].

[1] http://putka.upm.si/langref/turboPascal/0109.html [2] http://putka.upm.si/langref/turboPascal/047E.html

(I implemented the migration from AnsiString to WideString in the Delphi compiler when I worked for Borland. I know far too much about Pascal and Delphi strings.)

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

#17

Post by pmr_ »

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.

That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane.

Yes, compilers have become excellent at optimizing code, but they aren't magical. The generated code will have some semblance to the code we write. Eliding dynamic allocations is just not possible statically. Heck, we aren't even able to emit warnings for missing deallocations reliably and have to use run-time instrumentation for it.

Even in C++ or C, even with good compilers, we still have to go the extra mile if we want fast code.

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

#18

Post by hannibalhorn »

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…

You can specify the allocator to use with basic_string, and stack based allocators are possible. I've certainly used them with STL containers. It's just not the default.

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

#20

Post by ryandrake »

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 enormously with memory churn.

EDIT: Spelling :)

Post reply on HN