2. This looks to be a minor optimisation in the best case (select 1 … query vs. association load), but at worst you’ll execute many select 1 queries, one for each feature you need to check existence for. If you use .any?, the association is loaded once and cached, so you’ll only have one query. - ThreadSky

About ThreadSky

maxvolume.app • 27 days ago

2. This looks to be a minor optimisation in the best case (select 1 … query vs. association load), but at worst you’ll execute many select 1 queries, one for each feature you need to check existence for. If you use .any?, the association is loaded once and cached, so you’ll only have one query.

Comments

hacopian.de•27 days ago

Hmm, currently in my app there are two scenarios where this method is called: 1) where the association is preloaded, but potentially called multiple times; and 2) not preloaded and only called once. How would you handle that?

maxvolume.app•27 days ago

That would depend on how costly it is to load the association, and if it is expensive to do, how often the "cold" case occurs.

I don't think it's worth micro-optimising for the "association is not preloaded" case.

maxvolume.app•27 days ago

If there is a performance issue (e.g. high volume and expensive queries), I'd also explore alternative options. In the case of feature flags or user access rights, I'd consider caching those (as arrays per user) in the rails cache.

maxvolume.app•27 days ago

Final thought - DBs are pretty good at caching too. It might be ok to always call exists?, since that query might be really fast if you've already preloaded the association.

maxvolume.app•27 days ago

Really final thought - don't worry about any of this, unless you can prove with measurements that you have a performance problem here.

Posting Rules

Be respectful to others
No spam or self-promotion
Stay on topic
Follow Bluesky's terms of service

Comments

Posting Rules

Reply