Skip to content

Hang when value-to-print is very large #703

Closed

Description

@BenWiederhake

bpython (or maybe curtsies, no idea) hangs when the result is very large.
Example:

>>> s = "hello" * 1000
>>> s
[hangs, never returns]

This happens on all of the following configurations:

  • bpython version 0.17 on top of Python 2.7.13 /usr/bin/python on machine A
  • bpython version 0.17 on top of Python 3.5.4rc1 /usr/bin/python3 on machine A
  • bpython version 0.17 on top of Python 2.7.13 /usr/bin/python on machine B
  • bpython version 0.17 on top of Python 3.5.4rc1 /usr/bin/python3 on machine B

Where:

It appears to be independent of #607, and I guess it's a regression.

Doing the same in plain python2 or python3 works flawlessly and quickly.

Activity

  1. sebastinas commented on Nov 18, 2017

    @sebastinas
    Contributor

    From #717: Regression introduced in ef91741.

  2. sebastinas commented on Nov 18, 2017

    @sebastinas
    Contributor

    Pinging @ata2001.

  3. ata2001 commented on Jan 3, 2018

    @ata2001
    Contributor

    I'm on it.

  4. ata2001 commented on Jan 3, 2018

    @ata2001
    Contributor

    Okay, curtsies.formatstring.width_aware_slice() is slow for some reason on long strings. It becomes much faster when you pass the string in smaller chunks.

    For example:

    print("\x1b[31mhello" * 1000)
    

    won't hang because it gets converted to an FmtStr as 1000 chunks instead of one string

    >>> msg = fmtstr("\x1b[31mhello" * 1000)                                                                                                             [42/1785]
    >>> msg
    red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+re
    d('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red(
    'hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('h
    ello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hel
    lo')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello
    ')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')
    +red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+r
    ed('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red
    ('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')+red('hello')...
    
  5. ata2001 commented on Jan 4, 2018

    @ata2001
    Contributor

    This is definitely a curtsies issue, I'm going to create a PR optimizing curtsies.formatstring.width_aware_slice().

  6. BenWiederhake commented on Jan 6, 2018

    @BenWiederhake
    Author

    I took the freedom of overtaking you.

  7. mock commented on Jan 18, 2018

    @mock

    is that fix above the solution to the problem or just a workaround?

  8. BenWiederhake commented on Jan 19, 2018

    @BenWiederhake
    Author

    It's the actual solution. At least it takes the part of the code which is responsible for being slow and makes it so fast that it should no longer be the bottleneck.

  9. thomasballinger commented on Feb 12, 2018

    @thomasballinger
    Member

    This has been merged and a new release of Curtsies (0.2.12) has @BenWiederhake's patch. This is a big improvement that will help users now (there are at least 4 issues that are dups of this) so big thanks to @BenWiederhake. The behavior is from the bpython side is still empirically quadratic
    quadratic
    so still needs some work.

    Since this was introduced by width_aware_slice in ef91741 we might need to revert that. I don't remember the specific cases this was important for, should figure this out.

  10. thomasballinger commented on Feb 14, 2018

    @thomasballinger
    Member

    I've written a linear version of the line splitting behavior that made this still quadratic despite @BenWiederhake fix in curtsies with bpython/curtsies#110 but in the meantime we've stopped using the width-aware solution and released 0.17.1 to fix this behavior.

    I'm not totally clear on what width-awareness was solving for us – seems like some edge cases around where to wrap lines that have double-width characters or combining characters in them, but there haven't been any open issues about that. Eventually we can use this for formatting input and correctly position the cursor in the case of double-width and combining characters, but no issues open about that. I'm going to hold off on #731 until the case for why we need it is clearer and we're confident it doesn't cause any regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions