Python console output slowness

Support Bug Reports
21

i think you need to show some examples that it is an issue in Python, not Replit.

1 Like
22

I tried but I mean :confused: I can’t do much about that since all online IDEs work the same so he wouldn’t have been convinced it was a core programming (in general all programming languages operate this way) problem.

23

yea… Python in general is a high-performance language, it shouldn’t be used for something that demanding to the computer.

24

ok I just meant that the reason it’s slow is that the buffer is being bypassed, this being inherent to every programming language

1 Like
25

But in replit it only happens when the program is run with the run button, or imported in the interpreter (console). Maybe the run makes it do some sort of processing on the output :confused:

1 Like
26

maybe :confused: I always thought it was just buffer bypass slow in the server translates to slow output. Again, which gets pinned on server latency or what not, but the root cause being the saving of the cost of printing via buffer is trying to be circumvented. But I see, that is an interesting theory :smiley:

1 Like
27

This is very interesting indeed. @bigminiboss looks like when run, the console buffers. When run in the shell, the shell is not buffered.

Remember how people liked using typewriting effects?
That was when the console was not buffered.

1 Like
28

I mean I’ve been on replit for like 2 or 3 years so yes I remember that and no it was always buffered because back then people still complained about it; back then replit was just smaller and didn’t need to make the limit so low

2 Likes
29

Then, why is it buffered now?
This is a pain…

30

I have see no noticeable difference in speed between console and shell. But the most demanding things I am doing do a console clear and refresh every 0.2s. I do have to say that yesterday the console was very slow and this kind of makes mo wonder if the 8x programming environment of pro is always 8x or when replit feels like only.

1 Like
31

wait, the difference should be clear:
for messages longer than ~18 characters, the last characters print significantly slower than the first characters.

in shell everything works fine.