Performance issues with calcBounds about thredds HOT 10 CLOSED

@cheryldmorse , would be useful to include a link to the NcML file you were testing?

from thredds.

I was using this dataset in the tests: http://sos.maracoos.org/stable/agg_catalogs/weatherflow_agg_catalog.html?dataset=wflow700-agg

from thredds.

Unfortunately, that link does not provide the actual NcML file that you're using, nor the datasets that that file aggregates. So, I can't really reproduce your issue at this point.

from thredds.

@cwardgar The datasets and NCML file are available here: https://www.dropbox.com/s/sqfvhu5ckyrzeo3/station_700_agg.zip?dl=0
Thank you.

from thredds.

Okay, I've reproduced the issue. On my machine, in fact, the execution times are more like:
v4.3.24: 1692ms
v4.6.0-SNAPSHOT: 14514ms

I'm looking into it now.

from thredds.

Okay, I've tracked down the issue to ucar.nc2.iosp.hdf5.DataBTree

In v4.3.24, memTracker is null, and thus no messages are added to it.
In v4.6.0-SNAPSHOT, memTracker is non-null, and many expensive messages are added to it (complicated toString() implementations, mostly)

Assigning null to memTracker in v4.6.0-SNAPSHOT reduces the calcBounds() time from 14514ms to 2488ms on my computer.

I suspect that memTracker should be disabled in a non-debug context, but I don't know for sure. @JohnLCaron, please advise.

from thredds.

Never mind, John, I can see here [1] that MemTracker is only supposed to be used for debugging. I'll just refactor the source to check the debugTracker flag before each and every use of MemTracker.

[1] https://github.com/Unidata/thredds/blob/v4.5.4/cdm/src/main/java/ucar/nc2/iosp/hdf5/H5header.java#L222

from thredds.

Fixed in 4.6.0.

from thredds.

good job. i likely enabled it when debugging, and/or fixing some coverity defect. the hashmap should be null in the non-debug case.

from thredds.

This has also been fixed in 4.5.5:
be28036
c4bd0f2

We'll try to release 4.5.5 soon.

from thredds.