Posted: Sat Feb 21, 2004 1:25 am
Ech, couple comments...
"The op (me) wants to achieve global access to object instances. "
global = evil
Avoid globals in general.
-----------
"Why? Because I believe it's a better software engineering practice than just bashing at the database. "
Not necessarily. "Good" software enginerring practice is getting a working program that satisfies the customer's needs. Overanalyzing and trying to get a perfect program is impossible, so you just write something, and then you test it. I can't tell you how % of things like this I hear about only to run a test and see that there really is no issue.
For example, if you spend too much focus on this, and you miss an index on your database, then it won't matter what you do, data access will be slow (yes, this happened in one case). Get the overall program running, then identify specific problems, and then define what would make each problem "fixed" and then address those specific problems. As you get more experience, you simply will have less and less problems in your programs. But the key here is to just do it then test it.
In other words, you're trying to solve a problem that you have no clue if it is a problem even. Trust me, there are plenty of problems out there, but you need to be sure it's a problem first.
My last company was ALWAYS worried about our software being too slow. So there was CONSTANTLY a push to write more "efficient" code, even at the expense of readability and useabaility and re-useability. Problem one was that 95% of our time was in getting data from the database, not in our code... so they wanted to cache everything. Did nothing. Period.
Why? Because the effectiveness on the cache was not the right solution. Why? Because it was the right solution, but not to the problem we had. The problem we had (found by our resident nutjobber using VTune) was that the database drivers themselves were the issue. The timings in our code was fine, the SQL we ran on command line was fine on the servers, but when the same SQL ran through the drivers on the clients, it was slow as hell. The solution? Would have been to write a custom driver.
Lastly and MOST important, ANY time you are doing something to "speed something up" it is ENTIRELY worthless to do it until you make a test program to get timings. Unless you can say MethodA runs in X time and MethodB runs in Y time, its useless. More often then not, when you make your test program and get the timing, you'll probably find out it's fast enough already anyways.
---------
"It is extremely counter-productive to waste time worrying over performance. You should not worry about this while you're coding (assuming you're not doing anything totally crazy). Just try to write good, maintainable code. "
Smart man. You know there is going to be a problem somewhere. It may well be performance. But chances are not. Can tell you're a professional McGruff.
----------
"Wait and see how the finished product performs. Think about optimising if you really need to - and if it isn't cheaper and easier just to get new hardware."
If you charge your client say, 50 bucks an hour for your labor, and it will take a week to fix something, you just charged them 2000 bucks. For 800 bucks I can build you a computer that would blow your socks off... you'd be surprised how often a problem with performance can be solved just by upgrading the hardware. It's business, not perfection in code.
-----------
"Hmm .. if you're expecting hundreds of thousands of hits a day, caching is extremely important to reduce the massive server load."
Huh? Need to be more specific. What kind of implementation are we talking about? The most important caching is on the database itself. Tuning the database properly is everything. If a certain query is run often, the database should be caching it anyways. Not to mention if it is run often, the query should be hitting proper indices. The variance in speed of queries with changing the query a little or changing a setting on the database server is astounding. Apache is the same... the place to address this is in the database itself or Apache. Trying to share data/objects between users potentially across the world (am I really reading that right?) to save a few database hits is not what I would think would be a good start point.
"The op (me) wants to achieve global access to object instances. "
global = evil
Avoid globals in general.
-----------
"Why? Because I believe it's a better software engineering practice than just bashing at the database. "
Not necessarily. "Good" software enginerring practice is getting a working program that satisfies the customer's needs. Overanalyzing and trying to get a perfect program is impossible, so you just write something, and then you test it. I can't tell you how % of things like this I hear about only to run a test and see that there really is no issue.
For example, if you spend too much focus on this, and you miss an index on your database, then it won't matter what you do, data access will be slow (yes, this happened in one case). Get the overall program running, then identify specific problems, and then define what would make each problem "fixed" and then address those specific problems. As you get more experience, you simply will have less and less problems in your programs. But the key here is to just do it then test it.
In other words, you're trying to solve a problem that you have no clue if it is a problem even. Trust me, there are plenty of problems out there, but you need to be sure it's a problem first.
My last company was ALWAYS worried about our software being too slow. So there was CONSTANTLY a push to write more "efficient" code, even at the expense of readability and useabaility and re-useability. Problem one was that 95% of our time was in getting data from the database, not in our code... so they wanted to cache everything. Did nothing. Period.
Why? Because the effectiveness on the cache was not the right solution. Why? Because it was the right solution, but not to the problem we had. The problem we had (found by our resident nutjobber using VTune) was that the database drivers themselves were the issue. The timings in our code was fine, the SQL we ran on command line was fine on the servers, but when the same SQL ran through the drivers on the clients, it was slow as hell. The solution? Would have been to write a custom driver.
Lastly and MOST important, ANY time you are doing something to "speed something up" it is ENTIRELY worthless to do it until you make a test program to get timings. Unless you can say MethodA runs in X time and MethodB runs in Y time, its useless. More often then not, when you make your test program and get the timing, you'll probably find out it's fast enough already anyways.
---------
"It is extremely counter-productive to waste time worrying over performance. You should not worry about this while you're coding (assuming you're not doing anything totally crazy). Just try to write good, maintainable code. "
Smart man. You know there is going to be a problem somewhere. It may well be performance. But chances are not. Can tell you're a professional McGruff.
----------
"Wait and see how the finished product performs. Think about optimising if you really need to - and if it isn't cheaper and easier just to get new hardware."
If you charge your client say, 50 bucks an hour for your labor, and it will take a week to fix something, you just charged them 2000 bucks. For 800 bucks I can build you a computer that would blow your socks off... you'd be surprised how often a problem with performance can be solved just by upgrading the hardware. It's business, not perfection in code.
-----------
"Hmm .. if you're expecting hundreds of thousands of hits a day, caching is extremely important to reduce the massive server load."
Huh? Need to be more specific. What kind of implementation are we talking about? The most important caching is on the database itself. Tuning the database properly is everything. If a certain query is run often, the database should be caching it anyways. Not to mention if it is run often, the query should be hitting proper indices. The variance in speed of queries with changing the query a little or changing a setting on the database server is astounding. Apache is the same... the place to address this is in the database itself or Apache. Trying to share data/objects between users potentially across the world (am I really reading that right?) to save a few database hits is not what I would think would be a good start point.