If I have a notebook of normal size, where the dataset is cropped, it is much slower than in fullscreen, where the entire dataset is visible. Note: For me, it makes a difference if my notebook is fullscreen or not. This takes over 10 seconds, pops up a "Progress Dialog" and the front end is mostly unresponsive afterward. Next, we let the front end render the dataset in all its beauty ds Furthermore, the front end is as fast as it should be OutputForm Noteworthy, it is instantaneous although it shows the entire dataset. This takes about 0.01 seconds on my machine.
#FLEXI 12 RUNNING SLOW CODE#
This highlights the issue and I needed to delete the output cell just to copy the code here: v = ] So here is an example of 10x20 time-series placed in a dataset. Having said all that, we get an idea what exactly is the bottle-neck: front end rendering. resizing the window takes considerable more timeĭuring some of these actions, I see the small "Progress Dialog" popping up.
any editing in the notebook has a lag and particularly selecting something with the mouse becomes impossible.clicking the small arrow at the lower left to display the next 20 entries takes several seconds.scrolling the notebook is awful when you hover your mouse over one the time-series entries.hovering the header entries so that the links turn blue takes about 1 second.In particular, I saw the following issues:
#FLEXI 12 RUNNING SLOW PRO#
At home I have a Intel i7 Extreme with 8 cores (32GB RAM) and my macOS is running on the latest iMac Pro with 32GB RAM and the largest CPU available. This displays 20 rows and 7 columns and breaks my Linux and macOS front end. The issue is particularly noticeable when you have a data-set (in itself a formatted table with dynamic stuff) that contains things like TimeSeries. This includes dates, time-series, interpolating functions, etc. I reported this issue about 4 months ago for the pre-release because I experienced considerable slowdowns when working with things that are "nicely rendered" in the front end. Summary boxes and similar typesetting constructs are important to identify and understand expressions, but they should not make the system much slower, of course. We are improving Dataset in multiple ways, and WL 12.1 has focused on increased interactivity, Grid-like styling capabilities, storage of data in place, copy-paste, and other FrontEnd-related things. Many thanks for this example, We are looking into it too, and hope to have a fix very soon. The example I posted does not have any summary boxes though, and it still makes the FE quite literally unusable. We are working on a solution and will release it as soon as it is available. Both the TimeSeries objects of the coronavirus datasets and the InterpolatingFunction objects in the example given before typeset via summary boxes. We are aware of an unacceptable slowdown in some Dataset expressions, due to a bad dynamic interaction with the summary boxes of some objects. In case some of you missed it: There was an official reply from one of the WRI devs recently in our chat
0 kommentar(er)
