-
1
- #1
I have been participating in the forum 'Squaring the Circle' for some time. Recently one of the members put forward a quiz of sorts; interesting not for the answer but for how you get to the answer.
The thread is here: thread1229-1609213
gmmastros put forward a great sql solution (requiring sql server) that, he claimed, executed in a small number of milliseconds. I have not been able to replicate this solution, lacking the necessary skills to code it in ansi sql.
i coded a php solution that simply went through the numbers between 1234567890 and 9876543210 and tested each number for notability. this never completed on my test rig, constantly timing out.
I then replaced the code with a permutations generator and tested each perm. this worked fine and took about 25-35 seconds on my test machine.
I was shocked at how much slower this method was than a solution coded in a database description language (one using unions and joins - known slow downs).
After a day or so I recoded the solution again to work up from 1 to 10 digits, looping more than the first two solutions but with each loop being over a smaller (and decreasing) universe of possibilities. This code executed in 150 milliseconds on the same machine. Faith in php restored and a feeling of chargrinned embarrassment for yours truly...
I invite you all to read the thread, if only to get the history of the above.
The moral of the story here is multi-fold:
1. 'it works' is very seldom good enough. you need to give thought to optimisation and quite often the thought you give will be far longer than the actual coding. for those of us who code professionally, you need to explain this to your clients up front. In most joined-up projects that I have been involved in, the actual coding was less than one-third of the project delivery lifecycle (planning and testing being the rest).
2. footprint your code like mad so that you can determine processor/time hungry elements. concentrate your optimisation efforts on those areas.
3. loops of loops of loops are not necessarily a bad thing. php is good at looping providing the datasets are not too large.
4. consider using a database even for programmatic loops. it's easy to create in_memory tables in sqlite and mysql and often querying temp tables will be more efficient than iterating arrays.
5. don't shy away from breaking out into command line functionality. native C++ programs will nearly always execute faster than interpreted code.
6. trust your coding more than I did. I wasted more than an hour hunting for a bug in my code that did not exist. I have not examined the source code but I am certain that the problems I faced related wholly to an inadequate coding of the 64bit version of php.
7. consider using a php compiler if optimisation is genuinely an issue. I believe phc is good and there is also the facebook hiphop alternative.
The thread is here: thread1229-1609213
gmmastros put forward a great sql solution (requiring sql server) that, he claimed, executed in a small number of milliseconds. I have not been able to replicate this solution, lacking the necessary skills to code it in ansi sql.
i coded a php solution that simply went through the numbers between 1234567890 and 9876543210 and tested each number for notability. this never completed on my test rig, constantly timing out.
I then replaced the code with a permutations generator and tested each perm. this worked fine and took about 25-35 seconds on my test machine.
I was shocked at how much slower this method was than a solution coded in a database description language (one using unions and joins - known slow downs).
After a day or so I recoded the solution again to work up from 1 to 10 digits, looping more than the first two solutions but with each loop being over a smaller (and decreasing) universe of possibilities. This code executed in 150 milliseconds on the same machine. Faith in php restored and a feeling of chargrinned embarrassment for yours truly...
I invite you all to read the thread, if only to get the history of the above.
The moral of the story here is multi-fold:
1. 'it works' is very seldom good enough. you need to give thought to optimisation and quite often the thought you give will be far longer than the actual coding. for those of us who code professionally, you need to explain this to your clients up front. In most joined-up projects that I have been involved in, the actual coding was less than one-third of the project delivery lifecycle (planning and testing being the rest).
2. footprint your code like mad so that you can determine processor/time hungry elements. concentrate your optimisation efforts on those areas.
3. loops of loops of loops are not necessarily a bad thing. php is good at looping providing the datasets are not too large.
4. consider using a database even for programmatic loops. it's easy to create in_memory tables in sqlite and mysql and often querying temp tables will be more efficient than iterating arrays.
5. don't shy away from breaking out into command line functionality. native C++ programs will nearly always execute faster than interpreted code.
6. trust your coding more than I did. I wasted more than an hour hunting for a bug in my code that did not exist. I have not examined the source code but I am certain that the problems I faced related wholly to an inadequate coding of the 64bit version of php.
7. consider using a php compiler if optimisation is genuinely an issue. I believe phc is good and there is also the facebook hiphop alternative.