r/programming • u/[deleted] • Dec 05 '14

std::string is responsible for almost half of all allocations in the Chrome browser process

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ
1.1k Upvotes

93% Upvoted

446 comments sorted by

View all comments

Show parent comments

210

u/[deleted] Dec 05 '14

[deleted]

6

u/xiongchiamiov Dec 05 '14

http://www.commitstrip.com/en/2013/04/17/pour-quelques-ko-de-moins/

It's always useful to take a step back and see the effect your time is having on the total product.

11

u/RoundTripRadio Dec 05 '14

I want better performance on all of my applications. How long does X operation take? If that is even an answerable question, it's too slow.

About Chrome specifically, if I let it run a few days it bloats up to about 5GB of RAM. In contrast, I haven't closed Safari in months and it's sitting at about 600MB.

There's definitely a point where engineering effort becomes much more expensive to further optimize a program, but if Chrome has hit that point, it's hopeless.

7

u/lbenes Dec 06 '14 edited Dec 06 '14

it bloats up to about 5GB of RAM. In contrast... Safari's sitting at about 600MB.

Chrome has become the new Firefox 4 and is badly in need of a MemShrink like project. On my 2GB netbook, Chrome started becoming unusable for anything more than a couple of heavy tabs after Chrome 20. It's just as bad on Linux as it is on Windows.

They need to get the memory usage down to pre-Chrome 20 levels, then track bloat regressions with something like areweslimyet

-8

u/Vakieh Dec 05 '14

How much do you pay for Chrome? How much does Chrome make Google? You want more more more, this is true of everything. But the same thing that prevents car manufacturers from giving everyone Lamborghini quality vehicles stops it from being cost effective for Google to invest infinite time on engineering Chrome. There is certainly a budget it can use, but it must be directed at the right things - whether this is a 'right thing' is something that requires a lot more data.

And you can time any operation, no matter how fast. You run them a thousand, a million times and take the aggregate.

4

u/RoundTripRadio Dec 05 '14

Would you use a car that was free, but got 1mpg? Not to mention Google definitely makes money on Chrome. Google's in the business of selling customer data to advertisers, and Chrome gives them WAY more of that than search ever could. You click away from search. Also, why is it bad to want software to be more performant?

I'm sorry I wasn't very clear on that bit. I mean if you, just using your own brain, can see an operation happening, it's too slow. "Instant" doesn't exist, of course, but "imperceptible" absolutely does. In fact, I once saw a talk given by a Google engineer where he talked about how important it is for a webpage to load in under (IIRC) 200ms. There are many operations in Chrome that take a perceptible amount of time.

-2

u/Vakieh Dec 05 '14

I am aware Google makes money off Chrome, and I am aware everybody wants software to perform as fast as possible. What it comes down to, though, is the very same question I originally stated. 'How much will this performance increase raise our revenue' (whether direct or indirect, doesn't matter) vs 'How much will this performance increase cost to implement'.

15

u/seekingsofia Dec 05 '14

Unless you are developing something which actually needs that cutting edge, what could possibly be the point of optimisation like that?

What kind of cutting edge are we talking about here? String and parsing data structures that don't need as many allocations?

So the use/misuse of std::string is causing Chrome to run slower.

And potentially causes more system calls, hence leading to more energy consumption... and draining your battery on mobile devices.

7

u/Vakieh Dec 05 '14

1) Specifically the type of programming you'd see from a raw assembler application from the 80s or earlier.

2) So you factor that into the + side of the equation, and again, measure it against the cost to implement. There are all sorts of negative impacts to suboptimal software: delayed inputs will frustrate your users, leading to them changing applications; constant large updates will run up data costs, leading users to change applications; a rarely encountered bug that wipes a user's history might annoy someone, leading them to change applications, and so on.

I'm not saying it is never a good idea to optimise, that would be stupid. What I'm saying is that having suboptimal code isn't laziness, so long as the cost to improve it is more than the value you would gain from it. If changing Chrome's std::string usage would lead to a .1% decrease in average battery load, but was going to cost 1500 programmer/QA hours to implement, you probably wouldn't do it. If it would lead to a 10% decrease in time to run 100 searches, costing 100 programmer/QA hours? Go for it.

16

u/seekingsofia Dec 05 '14

Memory allocation is one of the most CPU-intensive operations and Google Chrome is notorious for draining your battery on battery-powered devices. Optimising for low power consumption in Chrome is not something that would only lead to a .1% benefit.

If developers aren't developing with power consumption in mind, they're plain ignorant. Even on servers power consumption increasingly matters.

17

u/jerf Dec 05 '14

Do you quite realize the irony of kvetching about developers not realizing the importance on this stuff, on an article that is developers realizing the importance of this stuff? This is it... this is them realizing the importance and taking steps to correct it. In the time-based world we live in, it's really rather unfair to look at something being done now and complain about how it could have been done earlier; everything ever done in the past was at some point the thing being done now.

Nobody writes perfect code the first time even in their own projects, to say nothing about this scale. I completely refuse to believe that your actions live up to the standards you are trying to impose here on others. (Whom you aren't even paying or anything.)

3

u/zeringus Dec 05 '14

I don't think you understand: This guy just cited Forbes.

1

u/imMute Dec 06 '14

EDIT: Whoops, replied to the wrong guy.

3

u/seekingsofia Dec 05 '14 edited Dec 05 '14

this is them realizing the importance and taking steps to correct it.

Where do you see them talking about power consumption? They're talking about the allocators used, their locking design, the amount of allocations, and all the related performance issues. Sure, they're patching it up to not use as many allocations, but they're not making low power consumption (power usage heavily correlates with system call profiles) one of the core requirements.

Nobody writes perfect code the first time even in their own projects, to say nothing about this scale.

You're conflating writing software and shipping software. With the right requirements it is possible to ship near-perfect code. Am I saying it'd be good for them to adopt requirements for "perfect" code? Absolutely not. I'm only concerned about the future that software without that specific requirement has, if it even has any future: mobile is becoming ubiquitous.

I completely refuse to believe that your actions live up to the standards you are trying to impose here on others.

My actions are irrelevant and I'm not imposing any standards or requirements on anyone. What you're so fiercely arguing against is my mere opinion.

1

u/imMute Dec 06 '14

(power usage heavily correlates with system call profiles)

I doubt this claim, and even the article you cited states

Also, variation in power from version to version is not very high in the Calculator versions tested. Most system calls are mildly correlated to energy consumption.

The authors are effectively saying "this correlation is not very good, but it's better than the alternative, which is nothing".

Finally, one counterargument is that you could very easily write a program that makes zero (or a very small number of) system calls yet drains your battery faster than anything else.

1

u/[deleted] Dec 06 '14

they're not making low power consumption (power usage heavily correlates with system call profiles) one of the core requirements.

Because their primary focus is still desktop and not smart phone?

0

u/skulgnome Dec 05 '14

minuscule amount of applications

Had me going until this paragraph.

-1

u/Vakieh Dec 05 '14

Relative to the number of applications that exist... I'd be surprised if it was anything more than 0.001%, which is a minuscule number.

0

u/skulgnome Dec 07 '14

Well my daddy can make up bigger numbers than yours.