PHP Developers Network

Hi,

I am creating a database driven website from a prototype I created in MS-Access 2007. I have been programming a long time in many languages over the years but I am new to Website design, HTML, MySql and PHP. I completed a script which is shown below and it works (it is a little test actually). If you study it you will see I used an include statement to bring in a function then I execute the function. My concern with the use of the include statement to get the function and execute it is the same concern that the person rises at the link below. That being "if it has to go to the disk to get a function rather than using a simple branch across memory and back then it must be pretty slow by comparison".

http://stackoverflow.com/questions/2483 ... rom-memory

So without (yet at least) figuring out how to get all PHP files to sit in memory (including all functions stored in php files which are going to be drawn in via the include statement) is this the fastest way to get at functions that will be called from different PHP script files. After reading the link above, I did do a google search " how to get php scripts to stay in memory (in cache)" and found an interesting article which I will eventually read
http://www.brandonturner.net/blog/2009/ ... ode_cache/
but that is a few steps ahead of my level at this point - LOL.

Thanks,
John

My first question when I read a post like this is: Do you have an actual performance problem? Not to sound harsh, but this looks like Premature Optimization at its worst. Honestly, you have two tiny scripts that do database access. My guess is that 99% of the time that script takes is fetching the data. Optimizing you database schema and queries would be the best thing to do.

You understand that servers cache all sorts of things. The file system, the database, web server and PHP all cache. And yes PHP has an add-on opcode cache. There are so many ways to improve performance that it is not worth discussing until you have a specific performance problem. With modern scripting languages, which do a lot under the hood, you can sometimes hurt performance by trying to be clever.

I would recommend designing you application well and then dealing with performance when it is a problem. You have separated out you Domain code to a separate file from your Presentation code. That is a good design decision. I would also separate the database connection code to a separate file as well. Beyond that, I would also recommend using OO and looking into existing PHP frameworks.

_________________
(#10850)

+1

I take it you're used to programming in languages where you're supposed to care about performance? PHP is not that way. Get your stuff working the way you want first, then you can think about installing extensions - if you even need to because PHP 5.4+ has this kind of thing built-in.

Why? Because you're spending... how much time exactly? worrying about something that will gain you a couple milliseconds here and there. It's not worth it right now.

Thanks guys. It is good to know that the approach I chose is good to go. I have a lot of queries I was going to handle this way and of course the strings are much bigger. Thanks for your other suggestions. It is true I am use to programming in one scripting language lately that does have speed issues. In this case with potentially many others using the web site I am creating I guess I am just thinking the same way.

I accidentally saved my prior response rather than submitting it (long day). Somewhere there is a draft saved. I have no idea how to get at it. Hopefully I don't end up sending a 2nd reply.

I would recommend organizing these into Model classes to promote reuse and make maintenance easier down the road. Inject you connection class into these for reuse/maintenance as well. If your queries are all variations of simple queries, you can look into the several good ActiveRecord and ORM implementations in PHP.

FYI - Ultimately for performance, everyone does the same thing -- that is push the rendered HTML output of the app to a cache closer to the user so they are served static pages (that are updated at intervals or when the data changes). Take a look at the libraries from projects like Symfony that are used by many other projects. I would recommend only reinventing the wheels unique to your application.

_________________
(#10850)

Thanks Christopher, You mentioned classes. After I came up with the ideas for having functions build the query strings I was investigating classes to see if that was the way to go instead. Going through this reminds me of learning object programming in VBA actually. In the end with time limitations it often comes back to just getting it to work and doing what you said earlier "deal with performance issues if they arise but they often don't". In other words don't fix it if it isn't broken. There is lots for me to learn about these languages (kind of obvious). After having learned 10 languages a pattern has emerged. Every new language has something unique which can take some time to get use to. What is totally new to me this time around is this switching languages mid stream (from HTML to PHP and back). PL1 was like that but I never completed the course (having gotten a job programming and I had no need for it). Having Javascript execute miles from the server on the client machine is a new twist again for me. I am trying to figure out (just by thinking about this) if the web page is fully built into a buffer before it gets sent out from the server down the internet to the client machine (it would make sense to do that so errors screens could be sent out properly rather than garbled with screen text that had already been sent out). Often I get these types of questions answered by doing experiments if pure thinking does not bring the answer. One language I learned called "Easy Language" (a language for market trading) had some very strange quirks (breaking rules of normal languages). Figuring out one quirk took 3 weeks of solid experiments. I don't see this area being that difficult. The other patterns by the way is not realizing something could have been done better until after it was done. However often it is fairly easy to fix up with the added experience. Anyway, lots of fun. Thanks for your help. I will just keep plugging.

John