performance notes/thoughts

[gregsadetsky]

I initially thought that the ~1s response time was due to the 'starter' render postgres plan we were using -- but turns out (yay pyinstrument! -- see image below) that the django template rendering is taking up the most of the response time, by far. the db/sql-ish part is basically fine (~60ms).

interestingly, get_gcal_link_from_event specifically is taking about 200ms, which could be shaved off by denormalizing/caching the google calendar event link in the event model. the issue there (like with any caching) is that any change to either the event object (which can be tracked in a save override), OR to the related venue, would have to re-cache the new google calendar link value. that's not super great/might be error prone (i.e. some change to something related to the venue might not be seen by one of the save overrides, and then the cached gcal link would become stale/incorrect). we'd also have to re-cache/denormalize all of the google calendar links for all of the events related to a venue on any change to that venue. not the end of the world, but annoying. -- done in 1ef14a2ed25b3716b022e1c6590756d61368513d

caching is not easy/annoying, so will have to give this some more thought.

(the number units below are seconds)

[gregsadetsky]

AH, obviously... let's just have /event/ID/gcal (like /ics) and redirect to gcal on a click, saving us from having to generate the gcal links for all events on the index page.......!! --- done in 1ef14a2ed25b3716b022e1c6590756d61368513d. after the fix:

(no mention of get_gcal_link... anymore! -- almost all of the time is spent in the template rendering...!)

[gregsadetsky]

ok we're doing MUCH better now by baking the event html on event and venue object saves (in 099d0073077eb5c380c783410e8c2cd1ac08e68e and a few further commits)! down to ~300ms for the page generation, which is much better. closing this for now!