Very slow area calculation in DownloadAlongAction.addToDownload

[naoliv]

Download relation 4661847 with its members, then select the members.
Run download along with the default values and wait some time. Note how log it takes to calculate the area.
Could this action be somehow optimized? (simplifying the data before processing?)
It seems that there are some duplicated data in its output (or maybe representing data with a lower resolution?) and I don't know if they could be increasing the processing time (due to data duplication):

(…)
INFO:   adding -3.176 -52.16
INFO:   adding -3.176 -52.16
INFO:   adding -3.175 -52.16
INFO:   adding -3.175 -52.16
INFO:   adding -3.175 -52.161
INFO:   adding -3.174 -52.161
INFO:   adding -3.174 -52.161
INFO:   adding -3.174 -52.162
INFO:   adding -3.173 -52.162
INFO:   adding -3.173 -52.162
INFO:   adding -3.173 -52.163
INFO:   adding -3.172 -52.163
INFO:   adding -3.172 -52.163
INFO:   adding -3.172 -52.163
INFO:   adding -3.171 -52.164
INFO:   adding -3.171 -52.164
INFO:   adding -3.171 -52.164
(…)

JOSM:

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2015-03-23 02:30:58
Last Changed Author: stoecker
Revision: 8149
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2015-03-22 23:16:08 +0100 (Sun, 22 Mar 2015)
Last Changed Rev: 8149

Identification: JOSM/1.5 (8149 en) Linux Debian GNU/Linux 8.0 (jessie)
Memory Usage: 247 MB / 10206 MB (124 MB allocated, but free)
Java version: 1.7.0_75, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u75-2.5.4-2
VM arguments: [-Dawt.useSystemAAFontSettings=on]

Plugins:
- Create_grid_of_ways (30892)
- ImageryCache (30892)
- OpeningHoursEditor (30962)
- PicLayer (30962)
- SimplifyArea (30962)
- buildings_tools (30955)
- conflation (0.1.7)
- contourmerge (1012)
- download_along (30892)
- editgpx (30892)
- geotools (31000)
- importvec (30892)
- jts (31002)
- log4j (30892)
- measurement (30892)
- merge-overlap (30988)
- opendata (31050)
- pbf (31010)
- pdfimport (30892)
- poly (31056)
- reverter (30990)
- scripting (30702)
- todo (29154)
- turnrestrictions (31034)
- undelete (30892)
- utilsplugin2 (31040)

[naoliv]

As I said in ​http://www.openstreetmap.org/user/naoliv/diary/37548, I will contribute with 10 dollars to have this plugin/algorithm faster than it is now.

[Don-vip]

On my machine, time is spent as follows:

• 14s for area computation in plugin
• 33s in JOSM core DownloadAlongAction.addToDownload (recursive)

A simple optimization (remove logs), makes the first delay go down from 14 to 4 seconds.

[Don-vip]

First optimization made in [o34081:34082]. Next one is in core.

[GerdP]

There should be no more performance problems, see r14868 and r14962.