|3 questions about performance in large systems|
| 10:07 am on Feb 3, 2013 (gmt 0)|
Each of these is to some extent a judgement call-- but you can't judge if you don't know the fundamentals, right?
#1 Say all your variables have something in common, like ending in ".html". Is it better to keep the shared part in each separate variable, or to add it dynamically as you go along? ("If longer-blahblah = some codition" vs. "If shorter-blahblah . 'extra-bit' = some condition")
#2 When does it become cost-effective (cost = time, server resources etc) to pull your variables out of the code and stash them in an entirely separate database?
Short-term answer in my case: "When you are at least two orders of magnitude bigger." But I'm still curious. Does it make a difference if the database lives on a different server? (I just read the fine print for my specific host. Databases associated with a domain live in the same geographical location, but not necessarily on the same server. This may explain why piwik can be so excruciatingly slow at times.)
#3 You've got two or more include files-- say, different ones for different directories, and then some things that are shared across more than one directory. Is it better to keep them parallel (Include A and Z, Include B and Z, Include C and Z) or nest them (Include A, B or C, each of which in turn includes Z)?
| 3:23 am on Feb 12, 2013 (gmt 0)|
1. whichever is the most readable and straight forward for someone later to understand is best, the difference in those 2 pieces would be negligible. Unless it is repeated a million times, which means it could probably be rewritten in a much more efficient way anyway.
2. not sure that's ever cost effective, extra db hit on every request to get vars? hard to say which is best for any software, when things are used system wide they should be somewhere central, preload them into some caching system or config file or db, depends.and yes, if the db is farther away it probably will take longer to talk to, ad if it's on every request then that can have a large impact.
3. i have seen both and measured them on specfic systems and I have chosen one or the other based on speed tests. Confusion is one of the biggest factors, also how easy it is to change. I like one central config that can then do the logic of what to include, which means every file has the same include and it never changes, then the including file can change anytime, central changes save time and resources.
| 10:51 am on Feb 24, 2013 (gmt 0)|
Now really, moderators...
I don't pretend to remember what name I originally gave this topic, but I am absolutely certain the word "large" did not appear anywhere in it :P
|Unless it is repeated a million times, which means it could probably be rewritten in a much more efficient way anyway. |
No, I don't think I will ever have a navigation footer that includes links to a million different pages, excluding* only the page you are currently on :)
* That is: it's visible in the list, but isn't an active link. It drives me bonkers when www pages link to themselves. Not fragments or "return to top", just "Oh, oops, I guess I'm here already".