Microoptimalization: Avoid creating new calendars in ServiceDate

[skjolber]

Summary:

ServiceDate.getCalendarForDate(..) used 4.5 % CPU time in one of our benchmarks

Steps to reproduce:

Run performance testing using Open Trip Planner

Expected behavior:

Run fast

Observed behavior:

Wastes time constructing calendars

Platform:

Java 8

[barbeau]

@skjolber could you provide the GTFS data you are working with?

I believe this is also the underlying reason why there can be out of memory errors on very large GTFS feeds.

[skjolber]

I'll have to ask permission if so.

[skjolber]

@barbeau What makes you suspect out of memory error on the Calendar? Also, which version of the JDK have you been using?

[barbeau]

Mainly my experience with http://gtfs.openov.nl/gtfs/gtfs-openov-nl.zip.

See CUTR-at-USF/gtfs-realtime-validator#123 (comment).

I haven't looked into it in detail but my assumption is that the exploded calendar_dates.txt (instead of representation in calendar.txt) is causing problems. And, if more Calendars are being instantiated that needed that could certainly cause problems - reading your comments again though I'm not sure that's what you meant. If you have any additional insight please let me know.

[skjolber]

I have not looked into the memory use, the above issue is intended for code that initializes a Calendar and just throws it away again after reading the day, month and year.

[sheldonabrown]

Any chance you can capture a stack trace during your performance testing? I think you'll find you are in a different section of gtfs-modules.