JOSM hangs when opening a large file

[Adrian]

What steps will reproduce the problem?

1. Launch JOSM
2. Open a large file (~60MB in .osm format)

What is the expected result?

The file is opened after a short wait.

What happens instead?

JOSM hangs at 100% CPU. It still has plenty of memory available when it hangs.

Please provide any additional information below. Attach a screenshot if possible.

This was OK in r9060. 10MB is still OK with r9229.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2015-12-31 13:54:58 +0100 (Thu, 31 Dec 2015)
Build-Date:2015-12-31 12:57:00
Revision:9229
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9229 en) Mac OS X 10.9.5
Memory Usage: 218 MB / 3641 MB (94 MB allocated, but free)
Java version: 1.8.0_66, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM

[Don-vip]

can you please share your file?

[Don-vip]

I have no problem to open ​http://download.geofabrik.de/europe/azores-latest.osm.bz2 (116 Mb after extraction)

[Adrian]

Replying to Don-vip:

I have no problem to open ​http://download.geofabrik.de/europe/azores-latest.osm.bz2 (116 Mb after extraction)

​http://www.overpass-api.de/api/xapi?map?bbox=3.44,43.26,3.54,43.33

[simon04]

I can reproduce (the benchmark output is enabled w/ mappaint.render.benchmark):

INFO: Open file: /tmp/xapi.osm (65363254 bytes) -- the file containing http://www.overpass-api.de/api/xapi?map?bbox=3.44,43.26,3.54,43.33
INFO: Undefined element 'note' found in input stream. Skipping.
INFO: Undefined element 'meta' found in input stream. Skipping.
BENCHMARK: rendering phase 1 (calculate styles): 1 min 50 s; phase 2 (draw): 2.1 s; total: 1 min 52 s (scale: 1759.0249065781031 zoom level: 13)

The rendering takes 2 minutes and JOSM is unresponsive in the meanwhile

---

Build-Date:2016-01-03 12:36:12
Revision:9274
Is-Local-Build:true

Identification: JOSM/1.5 (9274 SVN en) Linux Arch Linux
Memory Usage: 362 MB / 3504 MB (303 MB allocated, but free)
Java version: 1.8.0_66, Oracle Corporation, OpenJDK 64-Bit Server VM

CPU i5-2500K, no separate GPU, 16GB of RAM

[simon04]

Testing w/ r9060:

INFO: Open file: /tmp/xapi.osm (65363254 bytes)
BENCHMARK: rendering phase 1 (calculate styles): 2.7 s; phase 2 (draw): 2.5 s; total: 5.2 s (scale: 1785.7104575785763 zoom level: 13)

[simon04]

Most of the changes between r9060 and r9229 are related to #12104 … Do we somewhere have a performance problem (from 2.7s to 1:50min)?

[Adrian]

I don't know whether this is relevant, but the bulk of the data in my xapi extract is buildings (imported from the French Cadastre, so a large part of France would be the same).

[Don-vip]

Confirmed: r9081 is fast, r9082 is slow, it's caused by the partial fill.

[Adrian]

I can confirm that the workaround for this issue is to turn off the partial fill option in the mappaint style.

There is also a large number of overlapping landuses in my extract.

[bastiK]

In 9298/josm:

fixed #12279 - JOSM hangs when opening a large file

[bastiK]

This bug broke the intern cache in StyleCache, i.e. it piles up more and more equal objects. This causes a memory leak and apparently slows down JOSM.

I'm not sure what the consequences are for the normal user, but it certainly isn't nice to have this bug in a tested version.

[Don-vip]

Replying to bastiK:

I'm not sure what the consequences are for the normal user, but it certainly isn't nice to have this bug in a tested version.

Do you think we should begin stabilization? We can release 16.01 earlier and delay unstarted stuff to 16.02.

[bastiK]

Replying to Don-vip:

Replying to bastiK:

I'm not sure what the consequences are for the normal user, but it certainly isn't nice to have this bug in a tested version.

Do you think we should begin stabilization? We can release 16.01 earlier and delay unstarted stuff to 16.02.

It gets continuously worse (slower) during a session, when more data is loaded and displayed. I think it would be good to make a very early release now. Besides, we already have a few visible changes this year. :)

[bastiK]

In 9770/josm:

test StyleCache (see #12279)