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

#141

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

pubby wrote: post #127

bodyfour wrote: post #90

Earlier quoted context omitted.

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

What's wrong with free functions?

Nothing really, but it mean your extensions aren't really first class syntactically. A developer has to remember that they write s.size() but not s.count_utf8_codepoints().

Bjarne Stroustrup actually has an interesting proposal to fix this by unifying free functions and method call syntax in C++17 although the proposal sounds pretty aggressive to me: http://isocpp.org/files/papers/N4174.pdf Would be an interesting change.

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

#142

Post by mappu » Fri, Dec 05, 2014, 11:13 PM UTC

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…

Devirtualization for example.

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

#143

Post by wfunction » Fri, Dec 05, 2014, 11:14 PM UTC

Why in the world are they even using c_str so often in the first place? That makes me worry more about security holes than performance...

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

#144

Post by dragonwriter » Fri, Dec 05, 2014, 11:14 PM UTC

bodyfour wrote: post #140

dragonwriter wrote: post #131

Earlier quoted context omitted.

> 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. But then you'd have the problem with different extensions to the same base class used in different libraries used in the same project conflicting, so you'd also need to make a way to scope the extensions to prevent that.

No different than any other symbol name in the global namespace though.

Well, yes, but there's a reason that you generally avoid using the global namespace, and open classes basically make extensions to classes have the same problems that globals have.

(In Ruby, where open classes are a major and frequently-leveraged feature, this became a serious issue; hence, why Ruby 2.x introduced refinements as an alternative that provides much of the utility of open classes but with less opportunity for conflicts.)

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

#145

Post by mappu » Fri, Dec 05, 2014, 11:21 PM UTC

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…

>this exact issue appears to be the cause of all of my problems

You can't know that from the bug report alone just because it says Omnibox in it. Did you measure your own mallocs pre/post patch?

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

#146

Post by vardump » Fri, Dec 05, 2014, 11:26 PM UTC

pjmlp wrote: post #138

tedunangst wrote: post #124

Earlier quoted context omitted.

Neither of you are really answering the question. You still haven't proposed a language is better. When the half dozen browsers that represent about 99.9% of the browswer market all use C++, perhaps the explanation is not "They're all wrong."

Around 20 years ago we had quite a few systems programming languages to choose from. The widespread of UNIX into the industry, killed the other languages because they weren't the UNIX system programming language and other system vendors weren't able to fight against UNIX based Workstations. So like JavaScript in the browser, C eventually killed the alternatives in the workstation market. C++ was able to gain industry…

C++ bugs are sometimes - too often - faster to find even from disassembly than from source code. Seriously. Yes, it's a very slow approach. But you can see what's really going on, and the picture is shockingly different from the source code point of view. While disassembly is verbose, there's no syntactic sugar that can obscure true function. C++ features, like operator overloading and exceptions, locally hide actual functionality. I've seen another language that has a lot of different ways to do same thing and enabled write-only development. Perl.

No, disassembly listing is not what I typically use for debugging. Just one of the tools. The point is, something is wrong when disassembly can be easier to understand than source code!

So depressing when you need to deal with it often. Our best tool is not very good.

Well, all this puts bread on my table, so I guess I shouldn't complain too much...

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

#147

Post by vardump » Fri, Dec 05, 2014, 11:45 PM UTC

tptacek wrote: post #139

DannyBee wrote: post #125

Earlier quoted context omitted.

Of all the things you shudl expect from a non-C++ language, performance is highly unlikely to be on that list. If you can't get something to be performant with C++, it's pretty unlikely you'll get it to be performant with most other languages. (Unless you want to try it in fortran)

I expect C programs to outperform C++ programs, simply by virtue of being more explicit (about everything, from allocation to levels of indirection).

Not always faster.

Try comparing qsort to stl::sort...

Hint: stl::sort is a lot faster. It can inline the comparison function. Ok, it just shows how slow function pointers are. I'm assuming compilers still can't optimize the function pointer away in qsort.

Of course a specialized sorter in C would be faster, one that can inline comparison function. C++ copy pasting automation... err, I mean templates are useful, because it can often inline your function and data type in the algorithm without using function pointers. At cost of generating same or similar algorithm code multiple times bloating the binary.

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

#148

Post by vardump » Sat, Dec 06, 2014, 12:40 AM UTC

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

Performance wise it might give a false impression of being zero-cost if you micro-benchmark or are very selective what you consider as a cost. Handy for developer effort wise, sure.

Yes, it's often cheap or even 'zero-cost'. But you can't assume that to be always the case.

In an actual system it might be not so zero-cost when there are multiple concrete instances of generated code of the template. Each consume require actual generated machine code. Larger code size can have a significant performance cost. TLB and L1C cache misses are far from free. Neither is loading the larger executable for short life time processes. Extra page fault, caused by larger memory requirements, that goes all the way to disk is also rather expensive.

The whole picture is simply way too complicated to make blanket statements like that.

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

#149

Post by spinlock » Sat, Dec 06, 2014, 1:28 AM UTC

vardump wrote: post #115

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.

Shame you're downvoted, because you're pretty much right. Don't get me wrong, correct code can very well be written in C/C++. It's just 95% of the programmers using those languages are not very skilled. The programs tend to be wrong and fragile. In C++, most of this fragility derives from its C-roots. C/C++ is also a poor match to today's CPUs. It's very slow compared to what the hardware is capable of. Compare for e…

what languages are more appropriate for today's hardware? The majority of my experience in C (Linux) is on embedded hardware (and quite a few years ago). I've never run into wasted cycles before but that setup is really different from a modern cpu on a desktop.

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

#150

Post by groby_b » Sat, Dec 06, 2014, 1:39 AM UTC

rwmj wrote: post #82

ibebrett wrote: post #74

Earlier quoted context omitted.

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…

It has been answered, and according to the answer, there's an easy 20x-30x speedup to be had. Maybe your problem is not C++ per se.

I wouldn't be surprised if std::unordered_set would yield further speedup. (It doesn't look like you need the order criterion). Other things worth trying are:

* Not using a set at all - it seems most sets only have 3-4 elements. You might as well use a vector. * It doesn't look like your intervals overlap, and it looks like they're already ordered. interval_map may be unnecessary, and it might be worth keeping the data in a simple vector. * You don't want to copy object_set, either. A const-ref is more than enough * And finally, if you want to veer into nit-pick territory, you want to use range-based loops. It might or might not yield better compiled code. It's definitely much more readable.

  for (const auto& iter : map->equal_range(window))
    for (const auto& obj: iter->second)
      f(iter->first->start, iter->first->end, obj.c_str(), opaque);

I don't disagree with the abysmal error messages, or the thought that C++ is a beast to learn and control. But if there's one thing it does give you, it's decent performance, if used properly.

Let's put it that way: The browser people don't write C++ because they think it's such an awesome language :)