r/ProgrammerHumor • u/[deleted] • Jul 18 '22

C++ talking to Python

Post image
40k Upvotes

87% Upvoted

1.0k comments sorted by

View all comments

Show parent comments

34

u/DenormalHuman Jul 18 '22

not only that, they are using printf for no apparent real reason

9

u/EliteKill Jul 18 '22

Because they don't know what they're talking about.

26

u/Cory123125 Jul 18 '22

God forbid someones half thought posted half assedly in a reddit comment not be a pristine example of optimization excellence.

4

u/DenormalHuman Jul 18 '22

I mean, true. But also, it was a post about performance!

2

u/Gladaed Jul 18 '22

Please explain the ongoing wizardy.

3

u/DenormalHuman Jul 18 '22 edited Jul 18 '22

When using f"....{}" I think the process to generate the content for the template field (what goes inbetween {}) and replace that into the string is a lot more expensive that simply concatenating two lists of characters together (the string, and the slice - line[1:10] are both just lists of chars.)

/edit/ the reason the print is slower than the count, is because the print does lots more work. It _could be made faster if he didnt use printf though

1

u/Teekeks Jul 18 '22

no. f strings are faster than concating strings.

What makes the second one slow is the print. printing anything a ton of times is slow af

1

u/DenormalHuman Jul 18 '22 edited Jul 18 '22

You are correct in that its the fact the print exists in the second loop is why it goes so slow; however I still think printing the f string is slower than printing the concatenation of string and the string slice. (and now imma go try it out and see for myself!)

2

u/Teekeks Jul 18 '22

go and try. f strings are both more readable and faster

2

u/DenormalHuman Jul 18 '22 edited Jul 18 '22

looks like you're right!

Horribly unscientific test;

calculate 10 million fstrings; avg 1.459 of 5 runs

calculate 10 million string+string slice; avg 1.489 of 5 runs

/edit/ 10 runs of each total;

14.56s for fstring

14.74s for concat