Competition#calculate_members_only_places Slow

[Scott Willson]

Bouncing off Twitter to email, because this is more than I can fit in 140 chars

ryanrockets: I think the problem is it's never been done on our results, so it does them all. Possible to do it only for the events in the competition?

Theoretically, any change to racers or results can change a results's members_only_place. Examples: a misnamed racer is merged with another; a racers' member_from date is changed, a high result is changed to a DQ. This means that calculate_members_only_places needs to run each time a competition calculates. (Except for those competitions that don't care.)

We could do something like: store a calculate_members_only_places_at value for each race, and compare it the most Racer#updated_at and Result#updated_at values, and only run calculate_members_only_places if needed. I think, though, there are a number of edge cases, and that most of the time, something will have changed and we end up needing to run calculate_members_only_places anyway.

What you suggest is better: competitions like the WSBA BARR should only call calculate_members_only_places for the events that they care about. Of course, the Rider Rankings care about most events.

My last thought on making it faster is that the algorithm was written for clarity, not speed, and there may be some cheap improvements to be made there. I think you could replace the guts with a straight SQL update.

All that said, it usually runs once in the middle of the night, though, so it's "fast enough" most of the time. 

What I want to know is why I have the OBRA BAR calling calculate_members_only_places? I don't think it cares at all!

Scott

[Ryan Rickerts]

True, I wasn't benchmarking it on the server, just in dev mode on local data.  I was going to let it fly once the code is ready since you've got all this scheduled properly.

Where does the nightly/weekly stuff go again?  I've still got to get my USAC updates in there, too.

One thought for performance improvement and code clarity is having the depth of the competition stored in a parameter or constant, so calculate_members_only_places would return after it reached that number.  This param/constant would go in the SQL in source_results also.

RyanR>

[Scott Willson]

The competitions are calculated via FreeBSD periodic. See /usr/local/etc/periodic/daily/200.calculate_competitions

That's a good idea about limiting the place-depth for calculate_members_only_places. It could self-limit by the competition's points_schedule.size.