[OSM-talk] Serious JOSM performance degradation

[Safwat Halaby]

On Sat, 2017-11-11 at 22:57 +0100, mmd wrote:
> I can reproduce this locally on JOSM 13106. According to 
> cpu jvisualvm
> profiling (on Oracle JDK), most time is spent in method
> org.openstreetmap.josm.data.tagging.ac.AutoCompletionSet.add.
> 
> Best bet would be to create an issue on
> https://josm.openstreetmap.de/newticket

Thank you! So it's autocomplete as I suspected. I will file a ticket.
Is there a way to disable autocomplete in the meantime?

On Sat, 2017-11-11 at 22:27 +0100, Jo wrote:
> When working with public transport, the PT_Assistant plugin might be
> interesting for you. On the other hand, it might cause additional
> overhead.

Seems useful!

On Sat, 2017-11-11 at 23:09 +0100, Jan Martinec wrote:
> You can download somewhat-recent JOSM versions from https://josm.
> openstreetmap.de/download/ , I do see 12921 there. Also josm-latest,
> which
> is the testing version (currently 13101).

Thank you.

> Interesting file size.  What is a MiB?
> 
> If you are working with large file sizes and using the results
> elsewhere
> you should be using ECC memory.  Anything else and you stand a chance
> of
> corruption.
> 
> How much memory does your laptop have?

MiB is practically the same as MB in for the needs of this
conversation.

MB can be  vague nowadays, sometimes people use it when they mean
1000^2, and sometimes it means 1024^2.  MiB is explicitly 1024^2.
(lowercase mb is even more vague as it could also mean Mega-bit, which
is 256 bytes).

I am not working with astronomically huge memory, just a mundane
Overpass fetch-edit*-upload cycle. But perhaps it's all been smooth
because the dataset is entirely nodes, and no ways or relations. The
laptop is 4 GiB. Pretty average hardware.

*The edit is actually several custom GTFS scripts followed by some
manual touches but that's irrelevant for the performance issue. For
anyone interested in what I do with 30k stops:
https://wiki.openstreetmap.org/wiki/User:SafwatHalaby/scripts/gtfs