Modify

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#12279 closed defect (fixed)

JOSM hangs when opening a large file

Reported by: Adrian Owned by: team
Priority: critical Milestone: 16.01
Component: Core mappaint Version: tested
Keywords: template_report regression performance partial fill Cc: bastiK, Klumbumbus

Description

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

Attachments (0)

Change History (17)

comment:1 by Don-vip, 8 years ago

can you please share your file?

comment:2 by Don-vip, 8 years ago

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

comment:4 by simon04, 8 years ago

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

comment:5 by simon04, 8 years ago

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)

comment:6 by simon04, 8 years ago

Keywords: regression added
Milestone: 16.01
Priority: normalcritical

comment:7 by simon04, 8 years ago

Cc: bastiK added

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)?

comment:8 by Don-vip, 8 years ago

Keywords: performance added

comment:9 by Adrian, 8 years ago

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).

comment:10 by Don-vip, 8 years ago

Component: CoreCore mappaint
Keywords: partial fill added

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

comment:11 by Adrian, 8 years ago

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.

comment:12 by bastiK, 8 years ago

Resolution: fixed
Status: newclosed

In 9298/josm:

fixed #12279 - JOSM hangs when opening a large file

comment:13 by bastiK, 8 years ago

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.

comment:14 by Klumbumbus, 8 years ago

Cc: Klumbumbus added

in reply to:  13 ; comment:15 by Don-vip, 8 years ago

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.

in reply to:  15 comment:16 by bastiK, 8 years ago

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. :)

comment:17 by bastiK, 8 years ago

In 9770/josm:

test StyleCache (see #12279)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.