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

#61

Post by rwmj » Fri, Dec 05, 2014, 4:31 PM UTC

kibwen wrote: post #58

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…

I think this bears trumpeting: strings are hard! It's easy to gloss over their issues via garbage collection and pervasive heap allocation, but once you're in a domain where you care about stack allocation and avoiding copies you start running into difficult tradeoffs (above and beyond even the question of string encoding, which is a different beast altogether). Speaking as a dynamic language programmer who's trying…

Chrome is a web browser, not a real time operating system.

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

#62

Post by repsilat » Fri, Dec 05, 2014, 4:37 PM UTC

simias wrote: post #38

repsilat wrote: post #8

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. Surely some kind of string that lives on the stack can have its storage on the stack because the storage goes out of scope exactly when the object does. I think the only place you might run into trouble is if you try to `move` a stack-allocated string somewhere, because it'll invariably result in a co…

Without any compiler magic involved I don't think it's possible to implement that in C++ in a way compatible with the current std::string interface. The problem is not the allocation of the std::string object itself, it's the allocation of the underlying buffer containing the string. std::string has a static size, the buffer itself is dynamically sized. You could replace the heap alloc with something like calloc (or…

> std::string has a static size, the buffer itself is dynamically sized

Yeah, I guess if you're happy with the stack-allocated buffer being sized at compile-time (either switching or overflowing into heap-allocated storage if it gets too big) this all becomes very straightforward. If you want the stack storage to be runtime-sized (or resizeable) then I agree it's going to be a real pain in the neck. It doesn't fit into the C++ programming model cleanly at all. A pity.

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

#63

Post by kibwen » Fri, Dec 05, 2014, 4:42 PM UTC

adamtj wrote: post #47

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.

Reference counted copy-on-write strings are little landmines just waiting to blow your leg off should you venture into multi-threaded territory. If you use copies of such a string in multiple different threads, you may find that simply creating a new copy of the original string or any of its subsequent copies can cause an incorrect reference count which will trigger a double-free and a segfault at some later time, po…

This is where Rust is worth mentioning: its Rc smart pointer will statically prevent multiple threads from accessing the inner value, while its Arc (atomic reference counting) smart pointer will let you share the value while using atomic operations to adjust the refcount, same as C++'s shared_ptr. Rust's move semantics by-default also mean fewer refcount adjustments overall, since you can transfer ownership instead.

There's also a neat new copy-on-write smart pointer in the stdlib, though I have no experience with it yet: http://doc.rust-lang.org/std/borrow/enum.Cow.html

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

#64

Post by angersock » Fri, Dec 05, 2014, 4:44 PM UTC

pjmlp wrote: post #23

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

And here is where C shines compared to C++:

At least in C you know that strings are garbage, and you never pretend for a second that everything will be fine. C++ will claim "oh ho ho, we have a string type, don't worry!" and then people will get burned.

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

#65

Post by [deleted] » Fri, Dec 05, 2014, 4:46 PM UTC

gongar wrote: post #53

themoonbus wrote: post #52

Earlier quoted context omitted.

Same situation here... I have to clear my browser history every couple of months in order for it to perform adequately.

Yeah, same here. I've to clear history like every few weeks. Else it lags so badly.

[deleted]

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

#66

Post by IvyMike » Fri, Dec 05, 2014, 4:50 PM UTC

rwmj wrote: post #59

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…

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++?

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

#67

Post by titanomachy » Fri, Dec 05, 2014, 4:51 PM UTC

rwmj wrote: post #59

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…

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

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

#68

Post by kibwen » Fri, Dec 05, 2014, 4:52 PM UTC

rwmj wrote: post #59

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…

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.

Because they forked it from WebKit which is derived from KHTML, which has a history that stretches back to 1998. Better to ask which languages would have been a better fit for a web browser in the context of the late nineties that have had the staying power of C++ (I'm guessing you'll come up with a rather short list).

If you want to see an attempt to write a new browser engine in a language that is memory-safe by default, I suggest you check out Mozilla's Servo engine: https://github.com/servo/servo

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

#69

Post by ajuc » Fri, Dec 05, 2014, 4:53 PM UTC

kibwen wrote: post #58

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…

I think this bears trumpeting: strings are hard! It's easy to gloss over their issues via garbage collection and pervasive heap allocation, but once you're in a domain where you care about stack allocation and avoiding copies you start running into difficult tradeoffs (above and beyond even the question of string encoding, which is a different beast altogether). Speaking as a dynamic language programmer who's trying…

If you care about performance use std::performant_but_tricky_string. 99% of code doesn't care about string-related performance, but needs string anyway.

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

#70

Post by rwmj » Fri, Dec 05, 2014, 4:55 PM UTC

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++?

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.