While testing my strategies in historic tester I was curious, why it is 'bit' slow ...
When running under JForex SDK I was able to attach NetBeans' profiler and it showed some major performance issues. Please fix them.
At initial startup pretty long time is spent in reading of initial data from local cache files
95%
com.dukascopy.charts.data.datacache.LocalCacheManager.doReadData(...)
Inside there two major bottlenecks
- 'isWeekendTime()', I suspect that in case of sequential reads there is no need to invoke 'isWeekendTime()' for each tick - time of next weekend can be evaluated once and reused until reached, this will reduce number of invocations of 'isWeekendTime()' by 10000 times (or by how many ticks happen during a week)
50%
com.dukascopy.charts.data.datacache.listener.OccasionalDataOnWeekendsSubstitutionLiveFeedListener.newTick(...)
com.dukascopy.charts.data.datacache.filtering.FilterManager.isWeekendTime(long, com.dukascopy.api.Period)
- I'm not sure why 'Float.doubleValue()' is not used here - it looks like 'float->double' is converted via 'String', what is very CPU consuming thing ...
24%
com.dukascopy.charts.data.datacache.CacheManager.readTicksFromFile(...)
com.dukascopy.charts.data.datacache.TickData.fromBytes(int, long, double, byte[], int)
java.lang.Float.toString(float)
java.lang.Double.valueOf(String)
While running - I suspect overall performance can be improved by 50-70%, but the major simple bottleneck which has no specific business logic behind is here
com.dukascopy.charts.data.datacache.LocalCacheManager.newTick(com.dukascopy.api.Instrument, long, double, double, double, double, boolean)
com.dukascopy.charts.data.datacache.LocalCacheManager.getIntraPeriodFile(com.dukascopy.api.Instrument, com.dukascopy.api.Period, com.dukascopy.api.OfferSide, long)
com.dukascopy.charts.data.datacache.DataCacheUtils.getIntraPeriodFile(int, com.dukascopy.api.Instrument, com.dukascopy.api.Period, com.dukascopy.api.OfferSide, long)
java.text.Format.format(Object) <-- 23% of overall time is here
