BDKR wrote:All of the above said, what are some of the deciding factors for choosing to load all config vars into memory up front verse a lazy loading approach? It would seem that there are cases for both. I'm just curious to hear how some of you are thinking on this topic.
I can offer an answer about how I am doing it, and what my reasons are.
In the upcoming version of BNT, we wanted language editing to be trivially easy. In a previous version, we had a php file, with embedded html (!), embedded variables, and placeholder text. Then we moved to 100+ files, seperated for each page in the game, to reduce memory impact and load time.
What we've ended up with is a mix between the two. We have a single ini file with no embedded variables, html, or other non-language items. The ini file has categories, which correlate to the correct file in the game. Thus, in "main.php", we load all items from the category [main]. Its fairly straightforward.
At the 'creation' phase of the game, when the admin sets everything up, we load that ini file, and store the language variables in the database. Some files (categories) are larger than others, and some variables are used in multiple files.
During the play phase of the game, each page presenting text to a user does a database call, for the specific language categories needed. To date, the majority of the files use on average 3-4 categories, and approximately 50 lines of text.
We measured performance against a number of alternatives, and found this was the best solution. The alternatives included:
- One php language file, loaded on every page: Tremendously wasteful in processing time and in memory use. 2,000 variables defined for a page that only uses 20-50 doesn't make any sense.
- One ini language file, loaded into memory: A slight advantage over the php file, but again, wasteful for pages that don't need it.
- Multiple php language files, loaded on specific pages: While the processing time isn't terrible, when you approach 100 simultaneous users on an IDE-driven server, you see load increase rapidly due to the uncached, queueing disk seeks. Plus, the impact on translators was significant.
When we benchmarked the final choice (db-driven, ini-fed), I was a little shocked to see that it was somewhat better at the low-user count level, but fantastically better at the hundred-user count level. We're talking better than a 50% decrease in load!
It is definitely unique to an online game. Most websites (portals, news, blogs) are going to have roughly the same number of language strings on a given page. For our specific game, definitely not. We have one page with over 200 lines of text, and one page with only four. Its just a completely different problem set.
So thats why we went with ini-file-fed, db-driven languages. As a side note, we gained even *more* significant gains by using adodb's caching features. Because the language files literally change only when an admin makes the change, we can cache them until that change occurs. That leads nicely into the discussion of why we are working to add a built-in translator tool (which would notify adodb of the change), but thats another topic.
