What is more efficient: storing large list in socket or database hits?

I need to access a longish selection list. It is presented to the user in a drop down of checkboxes. The user can also just type to select so I need access to the list (for searching purposes) making it not suitable for streaming. I have two options:

  1. Hit database once and store entire list in socket and use that to do searches and to display checkboxes.

  2. Do a database hit every time I need access to the entire list.

Which is considered more efficient?

You could cache it with cachex or if it is that simple start an Agent process and get it from there.

4 Likes

You can also consider storing the list browser side if the list is static… in localStorage for example.

This way You can avoid 1 and 2

The downside is if the list changes, You will need to clear localStorage cache

2 Likes

Hmmmm … I hadn’t thought about either of those solutions. Unfortunately, the lists can change so I’m not sure about localStorage. I’ve never used that before so I’ll have to look into that.

So are both an Agent or localStorage more efficient than the Socket or database calls? I don’t have a good sense of what makes an app perform better.

How big a list are we talking here? I don’t think efficiency in this case is as important as what you can get away in terms of simplicity. Especially if the list is part of a form storing in assigns has the least amount of ceremony (none). You should only worry if there is actual concern about running out of memory. I don’t know much about your usecase, though.

My longest list has 700 entries. What threshold do you normally use where you start to look for alternatives to the socket?

As an aside … it get’s broken up into categories when it is presented to the user, so they are not sifting through 700 items. :slight_smile:

You might learn from great teachers :slight_smile:

Premature Optimization Is the Root of All Evil
Donald Knuth

Make it work, then make it beautiful, then if you really, really have to, make it fast
Joe Armstrong

6 Likes

It’s very hard to say! Some questions:

  • Is this dropdown on an always visible element, like in sticky liveview?
  • How often will it be interacted with?
  • How often is the page that it lives on visited?

If it lives on the primary page of your app and you have 100,000 users constantly interacting with it, then you’ll probably want to try out one of the suggestions above. If it’s on something like a settings page, storing 700 text entries in the socket isn’t so bad at all, even if you do have 100,000 users. There are a lot of variables! I’d say just do the easiest thing until it’s a problem (ie what the gorilla said :slight_smile: )

2 Likes

Thank you @arcyfelix, @kokolegorille and @sodapopcan! That was all super helpful

You’ve made me realize I’m overthinking this and worrying way too soon about performance. It’s all working using the socket so I’ll just leave it there for now and look into both the Agent or localCache at another time. Thank you @sodapopcan for that info about when to switch out of a socket solution. The list is in a drop down on the main liveview so it’s going to get loaded a lot. So I’ll keep in mind that neither the socket nor the database is a good long term solution. I’ll evaluate the other options when a) I’ve deployed and b) I’ve hopefully got enough users for it to be a problem. :slight_smile:

Thank you all for the advice!

4 Likes