Std::string half of all allocations in the Chrome browser process • Hacker News Board

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

#81

Post by ninkendo » Fri, Dec 05, 2014, 5:41 PM UTC

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.

> The C++ string library cannot bind the string to the stack frame since it doesn't know how long it's going to live.

Huh? If course it could, unless I'm not understanding you correctly.

A class like:

  class smallstr {
    char stack_str[128];
    char* heap_ptr;
  }

can easily (with enough logic in the public methods) store small strings in `stack_str` and once it grows larger, allocate some space on the heap, make `heap_ptr` point to it, and copy it over.

"since it doesn't know how long it's going to live" doesn't make any sense to me. A caller would just say:

  {
    smallstr s("foo");
    // do stuff
  } // stack_str[] is wiped clean with the stack, and a destructor would be implemented to `delete` heap_ptr if it was used.

I'm not sure what you're even driving at.

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

#82

Post by rwmj » Fri, Dec 05, 2014, 5:44 PM UTC

ibebrett wrote: post #74

rwmj wrote: post #70

Earlier quoted context omitted.

Almost all of Windows (including apps that predominantly do string and tree manipulation) is written in C++. Almost all of Linux userspace is written in C. These are still terrible, insecure, fragile languages which cause frustration and loss to programmers and users every day.

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 [2] has been answered now)

[1] http://git.annexia.org/?p=virt-bmap.git;a=tree

[2] https://stackoverflow.com/questions/27152834/how-to-improve-...

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

#83

Post by MrBuddyCasino » Fri, Dec 05, 2014, 5:49 PM UTC

roel_v wrote: post #37

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

"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. Equality works, Unicode works. Only downside: more memory needed, but nobody except the embedded guys care anymore.

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

#84

Post by bodyfour » Fri, Dec 05, 2014, 5:51 PM UTC

maxs wrote: post #32

barrkel wrote: post #16

Earlier quoted context omitted.

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…

It's called the short string optimization. It was used once but I am not sure if it is any more. C++11 move semantics may help a lot with string churning...

As others have mentioned some libraries do use it. It has tradeoffs though. In a "traditional" implementation sizeof(std::string)==sizeof(char * ) -- it keeps a pointer to the first byte of the text with the metadata (minimally: size and capacity) stored before it in memory. c_str() is just a "return p_;" and size() is something like "return reinterpret_cast(p_)[-1];"

Now to add the short-string optimization you need to do one of two things:

1. Add a small buffer we can point "p_" to inside the std::string itself. However, strings are very common inside of structures so this will bloat objects throughout your program

2. If you're clever you can use the lowest bit of the pointer to indicate that it's an interned string which would let you store 6 byte strings inside the pointer itself on a 64-bit machine (remember you still need the '\0' for c_str()'s benefit) However now c_str(), size(), etc all need an extra branch instruction. These are normally inlined methods, so now you've bloated/slowed the code instead.

Personally I prefer a keep-it-simple string implementation for most things.

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

#85

Post by vegancap » Fri, Dec 05, 2014, 6:00 PM UTC

csl wrote: post #14

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.

Thanks, that was a lot more helpful response :) I think the most confused I've been so far (coming from a PHP background) was all the different types of strings!

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

#86

Post by bodyfour » Fri, Dec 05, 2014, 6:06 PM UTC

TazeTSchnitzel wrote: post #41

zl4000 wrote: post #40

Earlier quoted context omitted.

Copy on write is not at all helpful in a language like C++ where concurrency can be concerned.

...how so?

If you have a single-threaded runtime then reference counts are cheap and easy. Once you need to support multithreading you need to use CPU atomic instructions to maintain the reference count safely. As the number of CPU cores increases the relative cost of this operation goes up.

COW strings were a very common optimization when 1-2 CPUs were standard. That's why it's there in GNU's libstdc++ for example. On a modern server with 24 cores it's pretty dubious. It'd only make sense if you were copying (and then not mutating) a lot of your strings.

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

#87

Post by DigitalSea » Fri, Dec 05, 2014, 6:08 PM UTC

dwild wrote: post #80

DigitalSea wrote: post #55

It all makes sense now. For some reason on my gaming PC which is pretty spec'd out in almost every way, Chrome will lag when typing into the Omnibox and requires me to close it completely and reopen it frequently. For a while I thought perhaps I had an issue with my CPU getting too hot, a bad plugin or faulty RAM, but this exact issue appears to be the cause of all of my problems. The only thing that seems to fix the…

On my Asus Transformer Book t100, that I use for all my personal stuff, I never have any issue with lag. In some rare case it can lag but it's temporary and then it's fast again. If your history is pretty big and it's all stored on a slow HDD, I can see how your IO could be the bottleneck.

I am a front-end developer, so my history grows a lot every single day. After a few weeks, my history is a culmination of documentation links, testing links, StackOverflow posts and more. I actually did some testing a little while ago and could see the bottleneck taking place. My CPU usage would spike up to 100% whenever I would type something into the Omnibox when I had a few weeks worth of history. I spotted this on a clean install of Chrome, I signed into my Google account, but disabled all plugins and it still occurred. Weirdly enough, not everyone seems to experience this issue.

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

#88

Post by twoodfin » Fri, Dec 05, 2014, 6:08 PM UTC

pmr_ wrote: post #17

simias wrote: post #3

Earlier quoted context omitted.

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 instrumentati…

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

I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable.

I can't find the reference now, but I thought I had seen some discussions at one of the ISO C++ meetings (from Google?) about potential standards changes to allow allocations to be elided when they're limited to some known scope.

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

#89

Post by kjetil » Fri, Dec 05, 2014, 6:13 PM UTC

richardwhiuk wrote: post #10

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…

Heh, as if Java's string was mundane, or even particularly well standardised. The implementation for String have varied in each of the JVM versions, and Android has a different version to the JDK. Java's string, depending on the string, length, JVM version and a bunch of other factors may or may not: - Be interned - so the result of "str1" == "str1" is compiler dependant (you must do "str1".equals("str1")). - Maintai…

Are you seriously suggesting that String incompatibilites are a big issues in Java?

String interning is specified in the JLS: http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#...

As far as I can tell, the substring "feature" has been there since Java 1.0 and was fixed in Java 7. Hardly groundbreaking stuff.

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

#90

Post by bodyfour » Fri, Dec 05, 2014, 6:15 PM UTC

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.

The real language problem is that classes are closed -- you can't add your own methods to std::string (other than operators) As a C++ program grows it's more and more tempting to make your own private string class (either by inheriting from std::string, encapsulating it, or reimplementing it) that interacts more naturally with your program's other types. I've done this myself. Of course this works great until you need to link to some other C++ library which has its own different string type.

Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished.