Half of the memory usage in Chrome is from std::string

> C++ fags will defend this

Attached: cppisashithole.png (2386x364, 52K)

Other urls found in this thread:

archive.fo/Xn1NM
groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ
twitter.com/SFWRedditVideos

archive.fo/Xn1NM

probably pajeets passing everything by value instead of using
const std::string_view&

Damn, 4 year old forum posts really make you think..

>White Chris Hamilton vs poojeet Ryan Sleevi

A web browser's primary job is to process and render HTML, CSS, and JavaScript, which are all provided to it through text. It would be natural for most of the memory used by a browser to be strings.

It's even worse, someone already did an analysis a while ago and the code is filled with retarded calls to .c_str() in order to pass a string to functions that then recreate another instance of std::string with the same data.

wtf I want to use char* and forget the null terminator now

Hello World!#2130x#021jk342320^password=hunter#*11123-=43
Segmentation Fault

strings are numbers in a society

> t. pajeet

>over half of memory allocations
>op thinks this means half of memory
He means that people fuck up and don't put const && on their type

>password=hunter
Based and redpilled

I wish more software was written by people who gave a shit

what the fuck

its almost as if...
webpages are made up of text

>and the code is filled with retarded calls to .c_str() in order to pass a string to functions that then recreate another instance of std::string with the same data.
First time ever using external libraries I see?

pretty sure user was implying this was in the same codebase

It wasn't due to external libraries, it was their own code passing strings around and recreating std::string instances with each call.
Read the full thread: groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ

Why did you kill blinky?

Strings are an array of char, which are ascii numbers.

stop

You->brain = NULL;

> const std::string_view&
Are you sure you’re not the retarded one here?

Attached: lurking.jpg (406x364, 38K)

Chrome is a web browser. The web is HTML, CSS and JS. Those things are all text. Text goes in strings. Case closed.

>Chrome is a web browser
>most web browsers serve webpages
>webpages are just text, their libraries are more text, their styling sheet is more text
>all the UI is mostly text
>rendered webpages are mostly text with maybe some images and maybe a video player

Am I really supposed to be surprised most of the memory is in string allocations?

Attached: 1530991338510.png (680x521, 94K)

Memory use is a good thing that's how everything stays pre loaded and works super fast? What the fuck how do you expect this shit to work?

Attached: 154000801ddddddddddddddddddddddddddddddddddddddddddd9623.png (483x470, 196K)

So ridicule them for it and maybe they'll come up with a better way to store text as data.

Unused Memory = Wasted Memory
Unused Cycles = Wasted Cycles

(phonefags will try to deny this)

not when you're just one application sharing resources with the rest of the computer of indeterminate memory and performance

This guy speaks the truth (16c 32t 128GB ram)

Why would you forget it? Never understood this argument. This only happens with unsanitized strings or off-by-one retardation.
>a memory leak is a feature
>cpu cycles spent on telemetry and botnet aren't stolen from you

>cpu cycles spent on telemetry and botnet aren't stolen from you
If they weren't being used elsewhere, and eventually the results of those cycles come to help you in some way, are they really stolen?

unless you are programming a video game console or some other embedded device you are never going to be the only program running on the hardware so the less resources you us the better

The program is privileged to run on your machine and you should in term have full control over what does and doesn't get executed.

std::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::stringstd::string

u mad, libtard?

But riddle me this anonymous, I have the choice of two HTTP libraries:
Lib1
>directly connects me to the HTTP server
>delivers me content from that HTTP server

Or:

Lib2
>directly connects me to the HTTP server
>but if there is enough CPU time, can also help to improve other parts of the software (via software updates during unused cycles, etc)
>delivers me content from the HTTP server
>(but the HTTP delivery code could have been updated by the potential updater from earlier to perform better)

Which option do you choose? Assuming both methods are as secure and non-tamperable as can be, etc.

>inb4 some "no software is intamperable!!" non-answer, we wouldn't be using HTTP if we were that paranoid

For the vast majority of programs, the language's standard string type will take up most of the memory usage.

99% of Jow Forums will pick 1 and be as stuck in the 00's as they always are

>everything is just text in a browser, from the source to the result
>somehow it's still near impossible in a sane way to zoom text separately from images

No, current built-in methods don't count, they don't remember zoom levels, especially not across different domains or tabs.

Attached: 1529016174061.jpg (1280x1556, 417K)

just write your own browser lmao
the power of open source

Alright, let's do so.
I'll start:
#include
#include // For exit()

int main()
{
FILE *fptr;

char filename[100], c;

printf("Enter the name of the empty HTML file to browse \n");
scanf("%s", filename);

// Open file
fptr = fopen(filename, "r");
if (fptr == NULL)
{
printf("Cannot open file, please install gentoo\n");
exit(0);
}

// Read contents from file
c = fgetc(fptr);
while (c != EOF)
{
printf ("%c", c);
c = fgetc(fptr);
}

fclose(fptr);
return 0;
}

Currently CLI only. So far it supports empty html and txt files according to the official HTML standards.

Your move, libtard.

Attached: 1529016929553.jpg (640x420, 45K)

IIRC GNU's libstdc++ won't re-allocate memory in this case - if you recreate an std::string from a .c_str() of another std::string, it will share the original's buffer. I think they have a global hashmap of all strings, or just a list of the last 5 calls to c_str(). Of course, calling .c_str also fucks up with cow optimisations, because if the buffer is shared, it has to make a copy because the string is mutable...

It should be main(void) according to spec
Is this web scale?
We should build concurrent processing

In theory it doesn't have to copy, it could be copy-on-write.

Half of all allocations doesn't mean half of all memory usage

It's a web browser. HTTP. All data is sent as strings... Maybe if browsers used some kind of bytecode from the start it wouldn't be a problem.

I don't understand the reasoning here. Why should we be careful of using std::string? It would make more sense if it was allocations-per-string-instance, but just total number of allocations says more about the Chromium codebase than std::string.

Good job. Now pass the file on the command line.

i'm trying my best senpai

No longer true. Copy-on-write optimizations are disallowed for std::string in C++11 and beyond.

I mean, if you're relying on std::string to optimize your string usage for you you're doing it wrong already

Strings are how they use the bytecode. The browser quite literally interprets English written by a webdev and carries out the instructions. It's really slow. This is why strange young people sometimes talk about "web assembly", which would be a server sending pre-compiled binaries to a browser... but that involves a lot of trust.

>but that involves a lot of trust.
>what are domain specific VMs

>which would be a server sending pre-compiled binaries to a browser... but that involves a lot of trust.
it executes on a virtual machine
thats the entire point of wasm

Well, there you have it. Servers and browsers will probably continue to interpret text though.

>write a half-hearted reply to a shitpost made less than 30mins earlier
>wonder why half--chan is almost constantly filled with shitposts
(pretend I put an NPC emote image here)

yeah just use const char*

I optimized 68234401 browser according to Terry A Davis paradigm (less lines = better). Follow RMS paradigm in order to use it (email the website to yourself, save the email as a text file and then open it with 68234401 browser). URN is the Uniform Resource Name, duh.

#include
#include
int main(void) {
FILE *fptr;
char filename[100], c;
printf("Enter URN: \n");
scanf("%s", filename);

// run over the file
fptr = fopen(filename, "r");

// render with divine intellect
c = fgetc(fptr);
while (c != EOF) {
printf ("%c", c);
c = fgetc(fptr);
}
fclose(fptr);
return 0;
}

Usage instructions:
1. save as "68234401 browser.c"
2. compile with e.g. gcc like so: "$ gcc 68234401 browser.c"
3. run the result e.g. "$ ./a.out"
4. enter URN, so any regular text file
5. get rendered upon

Licensed under CIA nigger license:
(I) Everybody that looks at the code will be classified as a CIA nigger and is free to get run over by me.

We need a logo! First apparently oc logo wins.

Attached: 1533670326331.jpg (620x349, 27K)

>Unused Memory = Wasted Memory
problem is when something else needs it and it's not unloaded

underated

...

lel

Are you new here? What is happening is multiple instances of the same data is being kept in memory. No performance improvement. Just retardation

You have no idea what you're talking about dude

protip: no one here does

it's not the lines that get you, it's the heap allocations

>heap allocations
I run those over

Please commit kys fren

Also, suddenly web servers would be responsible for supporting all platforms, instead of browsers providing that role. Another thing is that it would become more expensive to develop websites, because a larger amount of smarter people would be required to develop and maintain high-performance websites for any platform that can run a browser. At that point, one is better off developing their own client for a server, if that much performance is required.

You're only pointing that out because the code was written by a black female, you evil racist sexist pig.

I am on Firefox. Bye!

Kek normie fags and their chromes...

How cute.

You could save two lines by
while ((c = fgetc(fptr)) != EOF)

I absolutely see it, but it doesn't work for me. Prints nothing to stdout. I don't know.

fgetc doesn't return a char you sape

Just std::string_view you retard.

Lib1, obviously.

C++!
What are you a fag or something?

Where would the fun be in that

Attached: post-557433-0-54806200-1492781599.gif (65x33, 4K)

the irony in this post..

I don't understand. Could you explain this to a Java fag like myself?

Imagine if every time you passed an object as a parameter to a function you .clone()ed it instead.

kek

>half the memory usage in an application that primarily displays a bunch of strings on the screen comes from string type
user, I...

half of allocations is different from half of memory usage
my little hobbyist user can't be this cute

Doesn't this imply that the best way to build a browser would be in Perl?

or, you know, std::string&

string& adds another layer of indirection.

std::string and std::vector are bad abstractions and you can do them more efficiently.

And string_view doesn't? Now, I'd understand using string_view if the text you're processing is all allocated in a huge chunk, e.g. a web page. Sorry if that's what you were implying.
>std::string and std::vector are bad abstractions
explain yourself

No, that is the exact reason why C++ programs make so many string allocations
Because const char* are passed as const std::string& thus making a copy and then these are passed as const char* and it goes on and on.
And it also happens when you take a substr.
In these case you should use a string_view or a const string_view reference because it explicitly does not copy.

I think one part of user's point is that std::string does not simply represent a string. In reality it's an abstraction for a memory buffer that contains a string.

>using const char* in C++ code
you're just asking for it at that point
substrings is kind of an issue though, it depends on the application

It probably can't be helped with big, old codebases and/or calling into third-party libraries.
and yeah for substrings you should mind the lifetime of the referenced memory, I didn't mean that copying into a std::string is always a bad thing

A typical implementation of a std::string looks something like this in memory.
struct string
{
size_t capacity;
size_t size;
char *data;
}
To access the contents of the data buffer from a std::string& the processor must dereference one pointer to reach the std::string struct and then dereference another pointer to reach the buffer.
Meanwhile a string_view is just the following struct.
struct string_view
{
size_t size;
char *data;
};
Where size and data are copies of the members in the string struct. This only requires one dereference to access the "data" buffer.

>A typical implementation of a std::string looks something like this in memory.
No it doesn't, most stdlib implementations use small-string optimization. For short strings the double pointer dereference is a relatively more expensive operation, so the string is stored inline. For longer strings where reading the entire thing is more expensive, it's heap-allocated. Additionally with longer strings you typically don't read the contents all that often (compared to strings of just a few bytes), or if you do it's a full iteration.

No, just std::string_view you dumbass.
Read up on why std::string_view exists.

read the thread dumbass

Sure, but that still leaves two dereferences for large strings. That's a downgrade on string_view which keeps a pointer to its parent std::string's buffer, always requiring only one dereference.

For fucks sake you dumbass.
This is not why you use std::string_view.
You use std::string_view so that you don't make unnecessary allocations no matter what string type is passed in.
What the fuck do you think happens if I pass a const char* to a std::string&? It fucking allocates that's what it does.

void foo(std::string_view str)

I can pass an std::string, std::string_view, char*, const char*, or literally any other type convertible to convertible to (const) char* or std::string_view without allocating any heap memory at all. You can't do this with std::string&.

Fucking educate yourselves you dumbass pieces of fucking shit. This is why people hate on C++ because of dumbfucks like you who use the language without fucking know how to use it properly and thus make it look bad.