High CPU usage in Buku interactive mode on Windows due to pyreadline3 polling

[jackanory101]

# buku --debug
[DEBUG] buku v5.1
[DEBUG] Python v3.13.12

Windows 10

When dropped into interactive mode python.exe immediately starts consuming CPU cycles between 7~11% even when not actively using buku in prompt mode. When I exit buku, python.exe exits.

$ py313.sh pip show buku
Name: buku
Version: 5.1
Summary: Bookmark manager like a text-based mini-web.
Home-page: https://github.com/jarun/buku
Author:
Author-email: Arun Prakash Jana <engineerarun@gmail.com>
License-Expression: GPL-3.0-or-later
Location: C:\Users\tom\Documents\bin\apps\python\python-313\Lib\site-packages
Requires: beautifulsoup4, certifi, colorama, cryptography, html5lib, pyreadline3, urllib3
Required-by:

C:\WINDOWS\system32>py-spy.exe top --pid 16628

Collecting samples from '"....python.exe"  "....Scripts\buku.exe" -t biz: + geo:eire - dev:localhost' (python v3.13.12)
Total Samples 1100
GIL: 12.00%, Active: 62.00%, Threads: 1

  %Own   %Total  OwnTime  TotalTime  Function (filename)
 62.00%  62.00%    6.89s     6.89s   get (pyreadline3\console\console.py) <----- HERE HERE HERE
  0.00%  62.00%   0.000s     6.89s   _readline_from_keyboard (pyreadline3\rlmain.py)
  0.00%  62.00%   0.000s     6.89s   hook_wrapper_23 (pyreadline3\console\console.py)
  0.00%  62.00%   0.000s     6.89s   prompt (buku.py)
  0.00%  62.00%   0.000s     6.89s   <module> (__main__.py)
  0.00%  62.00%   0.000s     6.89s   readline (pyreadline3\rlmain.py)
  0.00%  62.00%   0.000s     6.89s   _run_code (<frozen runpy>)
  0.00%  62.00%   0.000s     6.89s   read_in (buku.py)
  0.00%  62.00%   0.000s     6.89s   main (buku.py)
  0.00%  62.00%   0.000s     6.89s   getkeypress (pyreadline3\console\console.py)
  0.00%  62.00%   0.000s     6.89s   _run_module_as_main (<frozen runpy>)
  0.00%  62.00%   0.000s     6.89s   _readline_from_keyboard_poll (pyreadline3\rlmain.py)

Summarized by ChatGPT

Bug report: High CPU usage in Buku interactive mode on Windows due to pyreadline3 polling

Environment:

• Windows (CMD)
• Python 3.13.12 (MSVC build)
• Buku installed via pip
• Dependency: pyreadline3 3.5.6 (installed as dependency of Buku)

Problem:
When running buku in interactive mode (prompt UI), the process continuously consumes ~7–11% CPU while idle at the prompt.

This occurs even when no user input is being entered.

Expected behaviour:
Interactive prompt should remain idle and consume near 0% CPU while waiting for input.

Actual behaviour:
Sustained CPU usage (~7–11%) while idle at the Buku prompt.

Investigation results:

• CPU usage disappears when running Python with -S (disabling site), but this is not directly related to Buku itself.
• Profiling (py-spy) shows the hotspot is inside:

pyreadline3\console\console.py → get()  
pyreadline3\rlmain.py → _readline_from_keyboard_poll()  

• ~62% of sampled time is spent in pyreadline3 console input polling functions.

• Stack traces show repeated calls to Windows console APIs such as:

  • GetNumberOfConsoleInputEvents
  • GetConsoleScreenBufferInfoEx
  • WriteConsoleW

Root cause:
pyreadline3 is using a polling-based console input loop on Windows in Buku’s interactive prompt, resulting in a busy-wait loop and sustained CPU usage while idle.

Impact:

• Constant CPU usage when Buku is open in interactive mode
• Unnecessary power/battery consumption
• Affects usability of interactive mode on Windows

Workaround:

• Avoid interactive mode (buku -s / non-interactive usage)
• Removing pyreadline3 stops CPU usage but breaks Buku’s interactive prompt due to missing readline dependency

Notes:
This appears to be a Windows-specific issue in pyreadline3’s input handling rather than Buku core logic.

[LeXofLeviafan]

This appears to be a Windows-specific issue in pyreadline3’s input handling rather than Buku core logic.

Maybe report this at pyreadline3 instead?

…Perhaps reproduce it with a reduction first, so that they can work on it without needing to deal with the entire Buku codebase though.

Try running a stripped down script like this (and check performance while it's running)

#!/usr/bin/env python
import readline

def read_in(msg):
    message = None
    try:
        message = input(msg)
    except KeyboardInterrupt:
        print('Interrupted')
    return message

read_in('[Press Enter to quit]')

[jackanory101]

Thanks for the test script - the upshot is, your simple script also shows problem.

I asked LLM and was told, in effect, that pyreadline3 is 'fundamentally broken on Python 313 [..] and is largely unmaintained'.

Also, I tried bypassing pyreadline3 but buku failed to run. LLM says buku needs, at the least, a conditional check to 'bypass readline requirement' for Python 3.13.

Here is LLM in full:

Synopsis: High Idle CPU Usage on Windows via pyreadline3 Conflict in Python 3.13

The Problem

When running buku in interactive mode (buku -i) on Windows using Python 3.13, the idle process consumes 7% to 11% CPU (effectively pinning an entire logical CPU thread) while simply waiting for user input.

Root Cause Analysis

Because buku explicitly imports and depends on the readline module, Windows environments rely on pyreadline3 to mimic this functionality.

Sampling via py-spy reveals that pyreadline3 enters a severe unthrottled busy-wait loop under Python 3.13's overhauled terminal subsystem (PyREPL). Out of 658 profile samples taken while completely idle, 96.6% of CPU execution time was caught spinning on line 542 of pyreadline3\console\console.py:

_readline_from_keyboard ➔ _readline_from_keyboard_poll ➔ getkeypress ➔ get (console.py:542)  
  

Instead of blocking properly and yielding to the OS, the dependency continuously hammers the console API, roasting the CPU.

Why buku Needs to Address This

1. pyreadline3 is fundamentally broken on Python 3.13: Upstream issues confirm it conflicts heavily with Python 3.13's native terminal architecture and is largely unmaintained.
2. Hard Dependency Locking: buku currently fails to run if readline is missing or uninstalled, preventing Windows users from utilizing Python 3.13's native, efficient fallback mechanisms.

**Suggested Solutions for buku**

• Short-Term / Band-Aid: Add a conditional check in buku's environment setup. If running on Windows with Python 3.13+, gracefully bypass the hard readline requirement or explicitly fallback to standard input() to allow Python 3.13's native, optimized PyREPL to handle the heavy lifting safely.
• Long-Term / Modernization: Deprecate the legacy readline/pyreadline3 architecture entirely for cross-platform interactive prompts and migrate to a modern, actively maintained library like prompt_toolkit, which handles Windows console events natively at 0% idle CPU.

[LeXofLeviafan]

…So it does reproduce as I was guessing.

In that case, first of all, it's best to actually create a corresponding issue in their repository. Describe it as "High CPU usage when invoking input()", include performance stats as you did in OP, and supply the script I provided for the purpose of reproducing; you could also include a link to this issue for sake of context completeness (e.g. "here's where it originally came up"). Make sure to include their library version (it should be listed in pip list output for the environment where you've been running it). Who knows, maybe someone will fix it on their side?

As for working around this, the best I can think of is making the readline dependency optional; but that would probably make Buku shell mode less convenient to use in Windows without said dependency (as that would break command history). I also believe that for most users this kind of extra CPU load would in fact be considered negligible 🤔

Alternatively we could look into this prompt-toolkit suggested by that ML tool, but that would require modifying the entire script to depend on it (instead of just invoking it when loading CLI), just to have a (supposedly) better implementation for a single (and fairly minor) usecase 😅

P.S. For future reference: if you're going to post large blocks of text (such as LLM output), I suggest wrapping them in collapsible sections such as this one

Here's the syntax (it's HTML-based but supported in Markdown – at least when it's rendered on a webpage):

<details><summary>The static text (after 🞂/🞃) goes here (in HTML syntax, e.g. <em>italics</em>)</summary>

Write your large Markdown block here (note: the blank line after HTML code is _not_ optional!)
</details>