octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59332] Variable Editor gets extremely slow wi


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #59332] Variable Editor gets extremely slow with large arrays
Date: Sat, 24 Oct 2020 11:09:42 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

URL:
  <https://savannah.gnu.org/bugs/?59332>

                 Summary: Variable Editor gets extremely slow with large
arrays
                 Project: GNU Octave
            Submitted by: philipnienhuis
            Submitted on: Sat 24 Oct 2020 05:09:41 PM CEST
                Category: GUI
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: Philip Nienhuis
        Originator Email: 
             Open/Closed: Open
                 Release: dev
         Discussion Lock: Any
        Operating System: Any

    _______________________________________________________

Details:

IMO the Variable Editor is a fantastic tool especially for debugging, however
its usability is severely hampered when using it with large arrays.
AFAICS (but I may be wrong) the causes are:
0 All cells of an array opened in the VE are re-rendered, even if only a very
small part is visible in the pertinent array subpane;
0 For each debug step, or return to the prompt, all variables open in the VE
are re-rendered, also variables that haven't been touched at all between the
last command prompts;
0 Same applies when the VE pane or one of its subpanes is resized, or gets
undocked.
Octave is almost completely inresponsive while the VE is being rendered; only
the m-file Editor might respond to some actions.

Would it possible to only render cell ranges that are visible in and/or just
outside the respective subpanes? I suppose it shouldn't be hard to find out
what array cell ranges are displayed. All cell widths and -heights, subpane
widhts and -heights and positions of subplane sliders, if any, are known.
Maybe Qt even has ready-baked functions for it.

I guess that when 1. has been fixed, 2. and 3. become less relevant as far as
performance goes. Obviously performance is usually second priority anyway
during debugging; but it is demotivating to have to wait sometimes tens of
seconds after each step before being able to proceed.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59332>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]