View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014487 | Scribus | Internal | public | 2016-12-20 14:46 | 2016-12-20 18:23 |
| Reporter | jeff | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 1.5.3.svn | ||||
| Summary | 0014487: [performance stress test] Doing a rectangle selection over thousands of items is slow | ||||
| Description | Providing a sample "torture test" benchmark file, in the hope that it can help optimize the selection algorithms' performance. I know this file is not really a "normal" scenario, but it's a good benchmark; if you can make it fast, anything will be fast :) | ||||
| Steps To Reproduce | Using the mouse, do a "rectangle" selection over one of the first two christmas trees (or both, if you're a bit crazy). Result on luya's 1.5.3 svn build from 2016-12-04: even an 8-cores Xeon will take minutes to do the operation. In an ideal world, it should take a few seconds at most, there probably exists a clever way to optimize that search algorithm (I'm not savvy enough to know how, though!) | ||||
| Additional Information | Grouping/ungrouping the selected items also takes a really long time, during which Scribus provides no feedback; ideally, it should show a progressbar for long grouping operations (better performance is kind of the point of grouping in some cases!) | ||||
| Tags | performance, selection | ||||
| Patch | No | ||||
|
|
|
|
|
Interesting... after doing a grouping on the 1st tree, rectangle-selecting the 2nd tree becomes MUCH faster, even though it has nearly the same amount of vectors. I have the "Outline" pane open if that changes anything... maybe this has something to do with the outliner's treeview rather than the selection algorithm? Is it trying to repeatedly update the view for each item while the selection or grouping is happening? (just throwing some ideas out there in case that helps) |
|
|
well, can you try to close the "outline" pane and check? :-) (but, yes, interseting stress document!) |
|
|
Aaah, a clever ruse indeed! Ok so... whether the outline is closed or open and unfolded, it makes no difference after all, so nevermind that. Even more curious now is that I can't reproduce the "extreme slowness" of selecting the xmas trees' vectors now. It "only" takes 10 seconds to do the selection. However, there is an issue that persists, with an earlier version of the file: ungrouping is extremely slow. In this new test file I'm attaching now, if you select the toplevel group ("Group12") and try to ungroup, it takes 2m30s (reproducibly) to do the initial ungrouping. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-12-20 14:46 | jeff | New Issue | |
| 2016-12-20 14:46 | jeff | File Added: so many vectors, so little time.zip | |
| 2016-12-20 14:46 | jeff | Tag Attached: performance | |
| 2016-12-20 14:46 | jeff | Tag Attached: selection | |
| 2016-12-20 14:51 | jeff | Note Added: 0043111 | |
| 2016-12-20 16:43 | ale | Note Added: 0043114 | |
| 2016-12-20 16:44 | ale | Note Edited: 0043114 | |
| 2016-12-20 18:23 | jeff | File Added: test2.zip | |
| 2016-12-20 18:23 | jeff | Note Added: 0043116 |
