Opened 13 years ago
Last modified 13 years ago
#3371 new bug
Random points is terribly slow with complex features
| Reported by: | pcav | Owned by: | cfarmer |
|---|---|---|---|
| Priority: | major: does not work as expected | Milestone: | Version 1.7.0 |
| Component: | fTools | Version: | Trunk |
| Keywords: | Cc: | ||
| Must Fix for Release: | No | Platform: | All |
| Platform Version: | Awaiting user input: | no |
Description
If random points is applied to a complex shape (I'm taking ITA_adm0, I think from OSM), generating even a few points takes ages, while CPU goes to 100%. With 1 point it takes a few seconds, with 10 it is already very slow, with 1k points I had to force quit. This on a low power machine, 4 cores Intel(R) Atom(TM) CPU N550 @ 1.50GHz.
Change History (6)
comment:1 by , 13 years ago
| Platform: | Debian → All |
|---|
comment:2 by , 13 years ago
Carson, do you (or somebody) have an idea for any optimalization? If not, I'd close it and wait for move to the analysis lib.
comment:3 by , 13 years ago
Please do not close it: it causes QGIS to freeze for ages, and users have to kill it, with potential loss of data. You can postpone to 2.0 if you wish.
follow-up: 5 comment:4 by , 13 years ago
Ok. Carson, what about threading and a small STOP button (ftools-wide)?
comment:5 by , 13 years ago
Replying to borysiasty:
Ok. Carson, what about threading and a small STOP button (ftools-wide)?
This is a possibility, but would likely require a full re-write of the tool. So far only the geometry tools and geoprocessing tools use threading. I will have a look and see what kind of alterations are required... though it is unlikely that I'll have time to implement anything before the next release :-(
Carson
comment:6 by , 13 years ago
| Component: | Python plugins and bindings → fTools |
|---|
it takes quite a long also on a much powerful machine... and it is confirmed that it seems to depend on the complexity of the input polygon.