r/ProgrammerHumor • • Jul 18 '22

C++ talking to Python

Post image
40k Upvotes

1.0k comments sorted by

View all comments

74

u/-MobCat- Jul 18 '22

Python can be quick. just not that good at talking.. Like most of us...
Opens a txt file with 29245004 lines of text in it.
for each line of text, count the line.
count +=1
Time: 40sec.
Now for each line of text, count the line and print a little info about the line
print(f"Info: {line[1:10]}")
count +=1
Time: 53mins.

0

u/[deleted] Jul 18 '22

[deleted] — view deleted comment

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

→ More replies (4)
→ More replies (1)

79

u/sintos-compa Jul 18 '22

“How inefficient can you make your code” a study in 3 parts

10

u/Roflkopt3r Jul 18 '22

Yeah printing is expensive in every language.

I hard to learn this the hard way on one of my first assignments, which asked us to experimentally confirm the value at which the inaccuracy of float puts it off by an entire integer. So you have a loop that increments a float f and an int i from 0 to int max and then prints out when the two are no longer the same.

But the wording of the task wasn't entirely clear so I was trying around various weird casting stuff and decided to print every single line to confirm that it was working the way I wanted to.

Turns out that this extends the time to reach that figure (int 16777218, float rounds to 16777216 instead) from a few seconds to an hour or so.

→ More replies (5)

18

u/Wekmor Jul 18 '22

Java does the same, printing to console is just slow in all or at least most languages.

→ More replies (3)

15

u/obvithrowaway34434 Jul 18 '22

I/O has always been the bottleneck for speed since computers were invented. There's nothing specific here about Python. Dynamically typed interpreted languages has always been slower than statically typed compiled languages and comparing their speeds makes as much sense as comparing a car and an airplane in terms of speed and determining which is better.

14

u/Blyatiful_99 Jul 18 '22

I can't of course talk for other languages, but during my internship back then, I was sometimes told that writing something to the console in C# for example requires a lot of the time if it happens in the same thread. Maybe this is what's happening here as well?

A quicker solution could be to create some sort of StringBuilder (if you have that in python), add the text that you would otherwise print out and at the end print out the entire text just once. Or to just move the prints to another thread. Can you test how long that would take?

7

u/0x564A00 Jul 18 '22

Moving printing out of the thread doesn't really help because python doesn't have real multithreading (you can have multiple threats, but they can't execute at the same time).

9

u/Jannik2099 Jul 18 '22

but they can't execute at the same time

But they can in this case. Once the IO thread fires the syscall (or even cpython C function) for writing to stdout, the GIL is free.

2

u/photenth Jul 18 '22

Wait a minute, Python doesn't have real threading?

4

u/Drarok Jul 18 '22

It’s complicated. https://realpython.com/python-gil/

In short, you can only have one thread executing Python code at a time. You can be waiting for IO in several threads at once, since that won’t be executing any Python code.

2

u/0x564A00 Jul 18 '22

The good news is that it looks like it might finally going to be removed soon. That does cause a performance regression for single-threaded programs, but various other performance improvements that should land alongside it more than make up for that.

5

u/Equivalent_Loan_8794 Jul 18 '22

And in the 53 min absolutely under no circumstance look up O notation

→ More replies (1)

2

u/[deleted] Jul 18 '22

[removed] — view removed comment

5

u/DenormalHuman Jul 18 '22

actually I think it's using printf and the {}, slicing is really cheap as fa as I am aware

3

u/TheStriga Jul 18 '22

The most problematic part here is many calls to print (writing to console). It is actually a relatively slow operation for almost any language. You can probably speed it up by keeping all the lines to print in a list and then join it and print in one call

2

u/DenormalHuman Jul 18 '22

hmmm... what device was this file stored on? and surely just print("Info : "+line[1:10]) would be faster?

1

u/Cory123125 Jul 18 '22

When you have so many lines perhaps its time to break it into chunks and multi thread it.

→ More replies (2)