Glad it was of any help.
I'll just leave my fix here for others who might get confused by my
previously screwed up example:
https://play.golang.org/p/slzcEm0Zka
On 16/06/17 10:53, James Pettyjohn wrote:
Thanks for the follow-up!
That ended up being the approach I took - map two levels
Thanks for the follow-up!
That ended up being the approach I took - map two levels deep (because
that's how the keys come through) and load everything at start up and use
as an immutable structure. While in dev it is using the old code
essentially and that's fine.
I also noted that internal
I think I misunderstood what you were trying to accomplish. Let me try
to rephrase and see if I'm getting closer:
- to accommodate template changes during development, you introduced
read-locking to your app.
- as a result, your reads in production are slow. Never mind the fact
that locking
I'm surprised that the memory overhead is significant - 100 MB is not that
much.
Assuming that you don't need atomic updates to the entire KV store,
partition the keys.
Does the periodic reload involve changing the keys? If not, you could map
the dataset into nested structs. However, you
