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

131–140 of 170 posts

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

#131

Post by dragonwriter »

bodyfour wrote: post #90
ajuc wrote: post #4

I've worked on a project that used all of these: std::string, QString, OString, char*. All were required by a different library that we needed. This is why a good string type should be in core language.

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…

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

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

#132

Post by vardump »

tedunangst wrote: post #124
vardump wrote: post #115

Earlier quoted context omitted.

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…

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

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

I didn't say they're wrong by any means! C++ is the horse and cart. Performance wise, the programming language automobile doesn't exist yet. Of course one should and must use what is currently available!

The best language for writing a web browser does not exist yet. Or for writing other similarly complicated applications with performance requirements.

So, yes, C++ is probably the best language for writing a web browser right now. The cleanest dirty shirt. Certainly not the safest, but out of high level languages it has the best performance. It has large enough work force, important if you're building a large project. C/C++ interfaces with current operating systems natively. And a lot of other considerations make it a sensible choice.

But C/C++ is rather far from what a language could be. It's very bug prone. Overcomplicated. Hard to maintain.

And it is slow. Not compared to other languages, but to CPU performance potential. I can write very fast software in C++ -- if I effectively fall back to assembler or at least compiler intrinsics. In other words, by being a human compiler.

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

#133

Post by MrBuddyCasino »

ahomescu1 wrote: post #130
MrBuddyCasino wrote: post #83

Earlier quoted context omitted.

It boggles the mind how many different ways to represent Strings there are in C++, and String handling in general is the major reason I'll never touch it (or C) with a 10 feet pole. I'm interested to hear though how the String handling in Java is broken. This is everything I have to know: - String - CharSequence - char[] / Character[] - StringBuilder Done. Finito. Strings are immutable, the GC will clean up after me.…

> Only downside: more memory needed, but nobody except the embedded guys care anymore. As an Android user, I care. Android needs 2GB of memory to run the apps that iOS only needs 1GB for (running Android on a tablet with 1GB has been painful for me).

Mobile borders on embedded imho, and I agree that Java wasn't the smartest choice there. I'm on IOS, so I don't really know, but didn't Google push for 512MB minimum RAM with Android 4.0, to better serve the emerging markets?

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

#134

Post by pjmlp »

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…

    mylib: DEFINITIONS =
    BEGIN
      copy_first_n: PROCEDURE [VAR out_s: STRING, in_s: STRING, n: CARDINAL ]
      RETURNS [error: BOOLEAN];
    END
Mesa at Xerox PARC - 1979, one of the influences for strong type systems programming languages.

But the 80's startups had to go build workstations based on UNIX.

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

#135

Post by nightcracker »

humanrebar wrote: post #78
zl4000 wrote: post #42

Earlier quoted context omitted.

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…

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

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

#136

Post by vardump »

MrBuddyCasino wrote: post #100
roel_v wrote: post #97

Earlier quoted context omitted.

Hehe, ignorance truely is bliss I guess. Just ask yourself: what size is a char in Java? To unearth 90% of the problems with strings in any language, ask two things: first, what size is char? Any secondly, what is the length of a string? If you cannot talk about these things for an hour, you don't really understand how computers deal with strings.

Actually, no. 90% of the problems with strings in any language is somebody screwing up the character encoding, usually out of ignorance. The fact that every object in Java has some overhead and probably needs some padding for alignment is utterly irrelevant. But since you asked: - 8 bytes generic object overhead per String - 4 bytes for the char[] ref - 12 bytes for the char[] itself, if non-null, plus probably 4 byt…

> - and 2 bytes per character stored

No, 2 bytes per code unit. A single UTF-16 character requires one or two code units. So a single "character" (code point in Unicode terminology) is either 2 or 4 bytes in Java. Additionally, a single Unicode character can require multiple code points.

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

#137

Post by Scramblejams »

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.

By the way, reference counting may not have to be as bad as it is. Looks like there's a lot of opportunity for improvement. See here: http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

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

#138

Post by pjmlp »

tedunangst wrote: post #124
vardump wrote: post #115

Earlier quoted context omitted.

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…

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 acceptance because C++ compiler vendors were actually C compiler vendors bundling C++ in their products, since C++ came from AT&T as well.

Additionally, the computers started to be fast enough for mainstream VM based systems.

The business application developers moved along to VM based languages, while the system programmers focused on the languages that were supported by larger OS vendors, C and C++.

All the compiler vendors selling system programming languages compilers that didn't enjoy first class treatment on a mainstream OS, either closed down or changed business.

So 20 years later, C and C++ became the only alternatives for systems programming, unless one wants to play with dead languages.

With Ada being used in projects that required it, or for software scenarios where human life are at risk like aviation, train control systems, medical devices and so on.

And now we are getting beaten every day in security exploits due to daggling pointers and out of bounds errors.

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

#139

Post by tptacek »

DannyBee wrote: post #125
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…

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

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

#140

Post by bodyfour »

dragonwriter wrote: post #131
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…

> 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.
Post reply on HN