alcohol
commented
5 years ago This sounds like a blatant premature micro-optimization with no real justification. The whole class once initialized will use roughly 337736 bytes. If you consider the opcache possibilities on top of that, it really is negligent.
Currently all the countries are loaded in memory whenever you want to do a lookup.
The typical usage of this library (I would argue) is to lookup information about "common" countries.
To avoid loading a massive array in memory, would it be an idea to separate the country information into different files grouped by approximate population size?
So maybe we have 3 groups of population sizes: high, med, low.
First the library will attempt to lookup information from the high population countries, then if nothing found, load + try the med file, etc.
Personally I think grouping the data by population size makes a lot of sense in how the library will be commonly used.
Alternatively, we could have an option to generate a compiled/cached version of "common" countries per-app. So maybe there's a way in this library where we can generate (by command) an optimised lookup table based on the apps commonly-looked up country information.