I sure as hell believe it. I'm on an older, slightly creaky Macbook Pro, and typing in Chrome's box is frequently a nightmare if I'm running something like a VM. Keystrokes lag tremendously.
Std::string half of all allocations in the Chrome browser process
51–60 of 170 posts
Re: Std::string half of all allocations in the Chrome browser process
#52I sure as hell believe it. I'm on an older, slightly creaky Macbook Pro, and typing in Chrome's box is frequently a nightmare if I'm running something like a VM. Keystrokes lag tremendously.
Same situation here... I have to clear my browser history every couple of months in order for it to perform adequately.
Re: Std::string half of all allocations in the Chrome browser process
#53I sure as hell believe it. I'm on an older, slightly creaky Macbook Pro, and typing in Chrome's box is frequently a nightmare if I'm running something like a VM. Keystrokes lag tremendously.
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.
Re: Std::string half of all allocations in the Chrome browser process
#54I'm not even sure if I do stuff like this in prototypes. My experience has been that using a matrix/arena/pool can speed a program up that has inner loop allocations by x7. I think the average pc can do about 10,000,000 heap allocations per second, but as far as I know it causes thread locking to some degree.
Don't many std::string implementations have small string optimizations? This is actually the first time I have every heard of C++ strings being the bottleneck of an application (and it seems that is even still up for debate here).
Re: Std::string half of all allocations in the Chrome browser process
#55It 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 issue temporarily is clearing out my browsing history every few weeks, otherwise the issue gets to the point where you can wait a couple of seconds for a word you have typed to appear.
Don't get me started on the performance of using Chrome inside of a VM, that is a whole other world of hurt right there.
Re: Std::string half of all allocations in the Chrome browser process
#56In a certain 3d game engine we use, the devs decided to refactor a lot of old code in the animation code which used a hashed string type to use their new all-in-one reference counted String type instead.
Safe to say this turned out to be a disaster for performance since every time an animation or not had to be evaluated from a name (which we ended up doing a lot), a string had to be allocated on the heap.
Some people sadly underestimate how bad objects which rely on heap allocation can be in performance-critical code.
Re: Std::string half of all allocations in the Chrome browser process
#57Earlier quoted context omitted.
Interestingly, with Rust, the borrow checker makes it statically safe to know when you can stack alloc.
You can also do it in a more limited set of cases in other languages using escape analysis. You can't provide it in all cases, but in a subset of cases you can show that the allocation never escapes a certain stack context, and therefore it's safe to stack-allocate. I believe the JVM does that in many cases.
Yeah, I wish .NET would do that. Just calling, say, String.Split is gonna involve at least two allocations. At high performance levels, a single allocation per piece of work can be noticeable. And fixing it is difficult. You can actually manually allocate managed objects on the stack, but that's pretty hadn't hacky, unsafe, and doesn't help fix functions you call.
Re: Std::string half of all allocations in the Chrome browser process
#58Earlier 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…
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 to break into systems programming, it took a long time for me to fully appreciate the difficulties around strings. And now that I do, I'm perpetually paranoid about how many allocations my Python programs are doing behind the scenes...
Re: Std::string half of all allocations in the Chrome browser process
#59The 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.
Re: Std::string half of all allocations in the Chrome browser process
#60I 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`.
Right, I guess I misunderstood the article. As I said, new to C++.