Python console output slowness

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

import time
string = "This is a string that is used for testing purposes.\nI wonder why it gets slow. Strange."
for i in string:

  1. 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

When using the shell, however, everything works fine.

1 Like

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.

Well, did the printing get slow during the test?

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

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

1 Like

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.

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 :sob:

1 Like

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

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

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

  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
1 Like
  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.

1 Like
  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 :smiley:

  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.

1 Like
  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

1 Like

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


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

1 Like

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

Hmm. this solution has no effects.

1 Like

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.

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)

1 Like