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

71–80 of 170 posts

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

#71

Post by titanomachy »

kibwen wrote: post #68
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.

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

This is awesome! Tons of respect for Mozilla for supporting this kind of research.

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

#72

Post by panzi »

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.

Sharing mutable buffers? Nope, you would still need to switch to immutable strings or copy the buffers.

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

#73

Post by panzi »

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.

> Almost all of Linux userspace is written in C.

Depends on what you count. Qt can be seen as (part of the) Linux userspace. KDE applications are usually written in C++ (partially in QML+JavaScript), Gtk applications are written in C or Vala (a few in C#). If you don't count DE frameworks basically the only thing left would be libc, which of course is C (but available in some form under every noteworthy OS).

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

#74

Post by ibebrett »

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

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

#75

Post by ibebrett »

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.

how do you "share" objects that multiple pieces of code wan't to own. you need to copy if you are passing around a mutable string.

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

#76

Post by humanrebar »

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…

Yes, COW mutable strings is problematic. It makes more sense to have immutable COW strings, so locking for access isn't a concern. Of course, C++ doesn't have proper immutable data, so a carefully designed interface would be needed.

That's not to say it's a perfect solution.

As far as incorrect reference counts, that's a quality of implementation issue. In a truly multithreaded environment, you'd use locks or atomics to ensure thread safety.

In other words, if you have a nice wrapper around a shared_ptr const>, I don't think most of what you wrote above really applies anymore. But, again, it would be even better if C++ had a proper concept of immutability.

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

#78

Post by humanrebar »

zl4000 wrote: post #42
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

No that's BS. `std::string` should be used where ever it is applicable. The whole issue that this post about chrome was talking about was dealing with a poor usage of `std::string`, such as passing c_str() to then go and construct another string instead of passing by const ref. Or building a set of `std::string` to simply check if a value exists. That's just shit code, not an issue with `std::string`.

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 char * stop : Better because you can write algorithms around this, but still, doesn't help with deque?

5. template on START_ITER and STOP_ITER : The best we have now if you need an extremely general solution. But I hope writing your implementation in headers is fine.

6. home grown type : a very popular choice, but http://xkcd.com/927/

7. boost::string_ref : maybe the best choice, as it can be created from 1-4 (and most 6's), but still doesn't work with deque.

...so give the rookie a break. But I'll support any comment in a code review about not accepting std::string by reference or by value in an interface.

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

#79

Post by ninkendo »

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…

> The problem is that std::string is not a good type to use as a parameter for various reasons. In addition to its aggressive allocation behavior, it's also fairly inflexible. What are the alternatives?

I think a more specific critique is that std::string is not a good type to use as a copy parameter (ie. a non-reference, non-rvalue parameter.) It's perfectly acceptable in scenarios where you're passing it as a const reference (ie. not transferring ownership) or passing it as an rvalue where it can be moved in-place.

Your critique (and suggestion to use string_ref) seems to be oriented more towards use cases where a mutated copy of a string (be it a substring or some other transformation) needs to be passed around... I don't think it's fair to say "it's not good as a parameter."

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

#80

Post by dwild »

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.

Post reply on HN