Skip to content

base64.b85encode uses significant amount of RAM #101178

Description

@AbdealiLoKo

Bug report

On the same string:

  • b64encode: RAM: 604MB, CPU: 79%, Time taken: 1.18sec and gave a result
  • b85encode: RAM: 6.9GB, CPU: 64%, Time taken: 45sec and crashed due to insufficient RAM (most likely)

b85encode takes up my entire RAM and crashes

On IPython:

In [1]: import base64

In [2]: contents = b'a' * 250 * 1024 * 1024

In [3]: %time len(base64.b64encode(contents).decode("ascii")) / 1024 / 1024
CPU times: user 489 ms, sys: 414 ms, total: 904 ms
Wall time: 974 ms
Out[3]: 333.33333587646484

In [4]: %time len(base64.b85encode(contents).decode("ascii")) / 1024 / 1024
Killed

Here is the GNU time stats:

$ /usr/bin/time /opt/python3.9/bin/python -c "import base64; print(len(base64.b64encode(b'a' * 250 * 1024 * 1024)) / 1024 / 1024)"
333.33333587646484
0.55user 0.39system 0:01.18elapsed 79%CPU (0avgtext+0avgdata 604008maxresident)k
0inputs+0outputs (0major+151155minor)pagefaults 0swaps

$ /usr/bin/time /opt/python3.9/bin/python -c "import base64; print(len(base64.b85encode(b'a' * 250 * 1024 * 1024)) / 1024 / 1024)"
26.08user 3.39system 0:45.86elapsed 64%CPU (0avgtext+0avgdata 6966080maxresident)k
512inputs+0outputs (2major+1756895minor)pagefaults 0swaps

I have gotten same results in Python 3.6, 3.7, 3.8, 3.9

Your environment

  • CPython versions tested on: Python 3.9 installed with miniconda
  • Operating system and architecture: CentOS 7, AWS t3.large machine

Linked PRs

Activity

  1. sobolevn commented on Jan 23, 2023

    @sobolevn
    Member

    I can confirm, that this still happens on main:

    » time ./python.exe -c "import base64; print(len(base64.b85encode(b'a' * 250 * 1024 * 1024)) / 1024 / 1024)"
    312.5
    ./python.exe -c   160.32s user 74.28s system 87% cpu 4:29.26 total
    

    Compare it to almost-instant 64 version (it uses binascii's C implementation):

    » time ./python.exe -c "import base64; print(len(base64.b64encode(b'a' * 250 * 1024 * 1024)) / 1024 / 1024)"
    333.33333587646484
    ./python.exe -c   0.91s user 0.26s system 98% cpu 1.187 total
    
  2. eendebakpt commented on Feb 1, 2023

    @eendebakpt
    Contributor

    I looked into the implementation of b85encode (in _85encode). The memory problems are caused by the fact that internally copies of the data are made. The copies consist of small chuncks, where each chuck has the memory overhead of a python object.

    • First with words = struct.Struct('!%dI' % (len(b) // 4)).unpack(b). There is a iter_unpack method in the Struct class, but it does not work as expected.
    • And then with a list comprehension chunks = [ ... for word in words]. In the case padding=False we can replace this with a generator which would save memory. For padding=True we need to modify the last element of the list, which does not work for the generator.

    The poor performance (compared to b64encode) is mainly due to the part (chars2[word // 614125] + chars2[word // 85 % 7225] + chars[word % 85]).

    To make any significant gains an implementation in C seems the most worthwhile.

  3. added 4 commits that reference this issue on Mar 13, 2023
    41c613c
    880b548
    b50cdb1
    9814dab
  4. added 2 commits that reference this issue on Nov 18, 2023
  5. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 26, 2023
  6. added a commit that references this issue on Mar 3, 2024
  7. added a commit that references this issue on Apr 21, 2025
    05ae5ad
  8. kangtastic commented on Apr 21, 2025

    @kangtastic
    Contributor

    Pinging this issue in hopes of finding a reviewer for my PR gh-102753. It's been over two years 😅

  9. 1 remaining item

  10. added a commit that references this issue on Dec 25, 2025
  11. added a commit that references this issue on Dec 28, 2025
  12. added a commit that references this issue on Jan 14, 2026
  13. added a commit that references this issue on Jan 18, 2026
  14. added 2 commits that reference this issue on Feb 6, 2026
  15. added a commit that references this issue on Feb 13, 2026
  16. added a commit that references this issue on Feb 15, 2026
  17. added a commit that references this issue on Feb 24, 2026
  18. added a commit that references this issue on Feb 28, 2026
  19. added a commit that references this issue on Apr 7, 2026
  20. added 3 commits that reference this issue on Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    performancePerformance or resource usagestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions