Python console output slowness

[markzhere]

1. Make new Python repl.
2. Put the following into main.py

import time
string = "This is a string that is used for testing purposes.\nI wonder why it gets slow. Strange."
for i in string:
  print(i,end="",flush=True)
  time.sleep(0.05)

3. Press run button.

The problem should be clear: the printing works well at first, then gets slow.

Let’s try going to the shell.

$ python3 main.py

When using the shell, however, everything works fine.

[savardo]

I don’t think its Replit that is causing the problem; it runs fine on my phone. Did you try closing other tabs on your browser and running it again.

[markzhere]

Well, did the printing get slow during the test?

[savardo]

no… i tried using a longer string and there were no signs of slowing down

[markzhere]

interesting. Maybe you did not notice the change in the speed.
Try changing 0.05 to 0.02.
You’ll realize how the delay will be 0.02 at first, and then turns into 0.1

[savardo]

Hmm, now i see the problem…
However, I believe it’s just your computer sending too many requests at one go, which is why it slows down.

[markzhere]

I know right, if the string is more than ~18 characters long it slows down.
It’s not the user’s problem; this problem did not exist three months ago,
and printing a string out is one of the easiest things python can do.

It makes no sense for this problem to exist

[savardo]

i think it’s just replit restricting the number of logs you can send in a period of time since console logging requires to send data to their machine and back to your computer.

I could be totally wrong about this

[markzhere]

I think you’re right.
@not-ethan Do you know if Replit could please solve this?

[bigminiboss]

I said in Text laggy when simulating typing in Python repls:

@bigminiboss

hey sorry for being a lil late to the conversation, but a big reason is that it’s just how it works. What programming languages do is that they store your current output to a buffer string which will print out once it reaches a certain length because printing something is a very costly operation and doing it so often by forcing it to flush (print out the buffer at only one character) is just supremely inefficient and having only a 0.04 second latency makes it lag. After this, when the user inputs something, it gives the console a bit of a break from the constant processing, that is likely where the lag is from.
Possible other causes I can think of:

1. printing unicode could be costly/laggy
2. inputting has some sort of buffer optimization to handle the user constantly inputting keybinds and printing out single chars without a buffer, and therefore once you run input the optimization helps your repl to run better.

@bigminiboss

replit runs by essentially taking your code, and running it on a server, it will then return your output which will be displayed. Replit has very, very heavy traffic, and while some of the lag may come from server latency, this sounds correct as I have tested on different much more lightly used server sets with what I believe to be the same specs and setups that can run text without glitching, thank you for bringing this to my attention, however!

1. try boosting since replit just halfed the power of CPUs
2. maybe just trying upping the delay latency
3. try finding some buffer optimizations lol
   – try using curses this is SUPER fast and is run & made in c (+1) as suggested here
   – try using rich

[markzhere]

1. CPU is not an issue. Printing is an extremely easy task.
2. Delay latency cannot be changed to suit whatever the limit is (~0.1). That’s very slow.
3. Using sys.stdout.write() and sys.stdout.flush() IS a more effecient way to print into the console, but with the console refresh limit that was set, this is useless.

in case you forgot, running the code in any other online python IDE works fine. 3 months ago this would have worked fine on replit. If the CPU is minimally used, we can only conclude that there’s a limit on the console flush rate.

Looks like the console refresh rate limit is the problem.

[bigminiboss]

1. No, printing is a very, very costly operation. I’m sorry if that shakes your world but it just is.
2. It can be, like literally 0.07 is pretty good
3. wdym console refresh limit? There’s no such thing replit sends code to it’s server and then sends back the output, I’ve tested on different servers with the same style and replit just has more latency, so you would need to increase processing speed to get it to run faster (since replit sends it slower, you need to have your code run faster). At a certain point, however, replit is just too slow so even if you maximize your speed, replit’s latency will slow it down. There’s no good way to do console animations on replit, trust me, I used to a do a lot

Why don’t you try curses it’s much faster since you only refresh portions of the screen that need to be refreshed

[markzhere]

1. The cost of printing in Python is not a major concern in terms of performance or computational resources. Printing in Python is a simple operation that does not require a significant amount of processing power or memory. The cost of printing in Python is negligible compared to other more complex operations, such as data processing or complex calculations. As a result, printing in Python should not be considered a costly operation.

2. A delay of 0.07 seconds for each character in printing in Python is generally considered too slow, especially for programs that require real-time or time-sensitive output. This level of delay would cause a noticeable lag between the time the program generates the output and the time it appears on the screen, which can be unacceptable for some applications.

[bigminiboss]

1. In this case it is; buffers are used because printing is too slow to do at once, so it is collected and stored until buffer size reaches a limit and it’s printed
2. again, if you think about it, this is related to the buffer. If printing at 0.04 is causing lag, then it’s, again, because the buffer is there for a reason, and it does it’s job, bypassing it causes the console to break
3. You are probably correct, since it doesn’t act this way for other servers, thank you for informing me. Keep in mind, again, that this is because of cost of printing. If replit were to allow that many printing operations, the server would crash

If curses documentation is absolutely confusing (its tutorials are too), why don’t you create a demo for “refreshing portions of the screen that need to be refreshed”?

? How about just trying to sit down and do a read through, that’s how I did it. In addition, just remember:
screen = curses.init_scr() or something and then screen.refresh() refreshes it

[markzhere]

Sad. Even the all-powerful curses do not work.
Replit, please fix this…

[markzhere]

The part that is confusing is how if you execute python3 main.py in shell, it prints without slowness.

[UMARismyname]

See if this makes a difference:

1. Go to the files tab, then click on the three dots in top right > show hidden files
2. Remove "stderred", "--", from the interpreter command

[markzhere]

Hmm. this solution has no effects.

[savardo]

I checked with other Python compilers. and it turns out that all of them have this issue. Some of them just stop outputting whereas some, like Replit, just output them slowly.

I believe Replit can’t solve this issue, it has to do with Python itself.

[bigminiboss]

yes, like I’ve said multiple times but @markzhere doesn’t believe me, it has to do with the cost of printing (that is, it takes a lot of time to print something)