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

151–160 of 170 posts

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

#151

Post by groby_b »

DigitalSea wrote: post #87
dwild wrote: post #80

Earlier quoted context omitted.

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

If you feel comfortable sharing your history, filing a bug on crbug.com with this info might help out the Chromium devs. (Don't share it right away - ask to have the bug closed to public view before you share)

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

#152

Post by SamReidHughes »

simias wrote: post #113
ninkendo wrote: post #81

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. 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`…

Well, you have to take the context of our discussion in consideration, I meant that you couldn't dynamically elect to allocate your buffer on the stack instead of the heap at runtime in the constructor. Your solution just allocates a 128B buffer on the stack for all strings which may or may not end up being used. That makes your string object 128B larger in all situations. Since we were talking about std::string, I'm…

g++'s sizeof(std::string) is only 8 bytes because it's a single pointer such that the struct can be reinterpret_casted to a const char * and you get the same thing that c_str() gives you. It's reference-counted (across threads!), copy-on-write. I don't think people would mind a 24-byte std::string (on 64-bit systems), which would consist of a pointer, size, and capacity, and which would allow 22-byte strings to be stored inline.

On Windows, sizeof(std::string) is 24 or 32 depending on 32- or 64-bit. sizeof(vector) is 12 and 24, respectively, of course. I believe the extra size of the std::string is for storing strings inline. I'd guess their implementation looks like struct { char *ptr; size_t size; union { size_t capacity; char buf[16]; } u; };, which sacrifices some size in favor of keeping the code paths simple.

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

#153

Post by asveikau »

humanrebar wrote: post #122
userbinator wrote: post #107

25000 (!!) allocations are made for every keystroke in the Omnibox. The Omnibox is no doubt far more complex than simple text box since entering characters into it can invoke things like network connections (for search suggestions), but 25k allocs is still a bit on the excessive side. Strings are an interesting case in that in general they are of indeterminate (and variable) length, which makes them somewhat difficul…

> Contrast this with a language like C, in which string operations are (unless the programmer writes or uses a library) far more explicit String operations are more explicit. Mostly. But some things (like sharing between threads, type conversion, and memory ownership) are very implicit and unsafe. Some of the implicitness to C programmers is so familiar that they don't notice it: /* 1. This function returns an error…

Nitpick: I don't think the output buffer would be const.

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

#154

Post by blt »

twoodfin wrote: post #88
pmr_ wrote: post #17

Earlier quoted context omitted.

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…

I think the right approach is to get a decent high level understanding of how compilers work. Some surprising optimizations and failures to optimize become a lot clearer. For example, SSA makes it obvious why there's absolutely no penalty for using lots of named temporary register-sized variables.

Then learn your particular compilers' abilities by research and reading your assembly output. If you're depending on an optimization, always read the output. You might be pleasantly surprised as often as you're disappointed.

Understanding the rules of the language are important too. In C++, pointer aliasing and the worthlessness of 'const' are huge obstacles to some seemingly easy optimizations.

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

#155

Post by pja »

nostrademons wrote: post #98
rwmj wrote: post #82

Earlier quoted context omitted.

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

To be honest, I think gcc has pretty much caught up with clang with gcc-4.9 when it comes to error message quality.

I have a slight preference for the way clang chooses to highlight the entire AST parent node that it thinks is responsible for the error, but the approach g++ takes is perfectly clear.

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

#156

Post by pja »

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…

Does folly "just build" on current Ubuntu / Debian boxes now? When it first came out I had enormously trouble getting it to build at all.

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

#157

Post by pja »

nightcracker wrote: post #135
humanrebar wrote: post #78

Earlier quoted context omitted.

There's a right way to do it. It's not the obvious way. Berating people for coming to terms with that isn't helpful. It's not their fault that C++ only really supports std::string out of the box. What are the alternatives? 1. const std::string & : what if I have a vector ? 2. const char * : what if it's not null terminated? 3. const char * and size_t : Better, but what if I have a deque ? 4. const char * start, const…

#5 and many, many other reasons is why C++ desperately needs a standardized range type. Let's pray it comes in C++17.

What would a range type offer over a pair of iterators?

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

#158

Post by sedachv »

IvyMike wrote: post #66
rwmj wrote: post #59

Earlier quoted context omitted.

Or proper garbage collection so you don't need to worry about who owns the string and you don't have the big overhead of ref-counting. Why on earth are they using C++ for a web browser anyway? That's about the worst possible choice of programming language for that problem domain.

So which web browsers are not written in C++?

C: Lynx, w3m, Mothra Java: Lobo, gngr (https://gngr.info/) Limbo/Inferno: Charon Lisp: Closure, eww

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

#159

Post by hutattedonmyarm »

titanomachy wrote: post #67
rwmj wrote: post #59

Earlier quoted context omitted.

Or proper garbage collection so you don't need to worry about who owns the string and you don't have the big overhead of ref-counting. Why on earth are they using C++ for a web browser anyway? That's about the worst possible choice of programming language for that problem domain.

All 5 major web browsers are written in C++. EDIT: Chrome, Firefox, Safari, IE, Opera

Sure that Safari is C++ and not Objective-C?

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

#160

Post by srj »

rwmj wrote: post #70
IvyMike wrote: post #66

Earlier quoted context omitted.

So which web browsers are not written in C++?

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's fragile, insecure, and terrible about them? I've written C/C++ (among other languages) for years at work and it's quite rare that I see a bug that could be attributed to the language.
Post reply on HN