Re: [PHP] Re: Hidden costs of PHP arrays?
On Jan 29, 2009, at 6:07 PM, Eric Butera eric.but...@gmail.com wrote: On Thu, Jan 29, 2009 at 9:02 PM, Paul M Foster pa...@quillandmouse.com wrote: On Fri, Jan 30, 2009 at 11:10:16AM +1100, Clancy wrote: snip As a former assembly language programmer I have some idea of the vast amount of thumb twiddling which is going on behind-the-scenes when I make some apparently simple request like the one to get my phone number. Undoubtedly most of this occurs in the murky depths of the operating system, but if there were any simple way to avoid adding to it unnecessarily it would be nice to know about it. Ahhh, finally someone who understands this principle. There's simply no reason to waste cycles if you don't have to. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Flip side of the coin: also no point in wasting 10 hours accomplishing something that can be done in 2 on a management screen that rarely gets used. :) I know this well. I also work in a framework where 8 nested foreaches can be found. Arrays are hardly expensive in my position... -- http://www.voom.me | EFnet: #voom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php No seriously... http://voom.me | EFnet #voom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Hidden costs of PHP arrays?
-Original Message- From: Paul M Foster [mailto:pa...@quillandmouse.com] Sent: Thursday, January 29, 2009 8:02 PM To: php-general@lists.php.net Subject: Re: [PHP] Re: Hidden costs of PHP arrays? On Fri, Jan 30, 2009 at 11:10:16AM +1100, Clancy wrote: snip As a former assembly language programmer I have some idea of the vast amount of thumb twiddling which is going on behind-the-scenes when I make some apparently simple request like the one to get my phone number. Undoubtedly most of this occurs in the murky depths of the operating system, but if there were any simple way to avoid adding to it unnecessarily it would be nice to know about it. Ahhh, finally someone who understands this principle. There's simply no reason to waste cycles if you don't have to. If that's REALLY your bag, just plot all of your functions in Assembly, first! https://www.scriptlance.com/cgi-bin/freelancers/project.cgi?id=121743701 3order=bid%20DESC I, for one, will keep efficiency in mind--but if I spend a couple extra cycles to relieve myself of an extra 20 lines of code, I think I'll sleep just fine. :) Now, if I was programming embedded systems or time-critical transaction processing software, that might be another story. (Then again, if that were the case, I might not be playing with an interpreted language to begin with.) My 2c. // Todd -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Hidden costs of PHP arrays?
On Wed, 28 Jan 2009 00:50:18 +, nrix...@gmail.com (Nathan Rixham) wrote: Clancy wrote: Also what the relative virtues of defining the same set of fields for every contact, as against either defining only the fields which actually hold values, as in the following examples? a: $contacts['clancy']['home_address'] = 'jkjkjk'; $contacts['clancy']['home_phone'] = 0123 4567; $contacts['clancy'][' office_address''] = ''; $contacts['clancy']['office_phone'] = ''; $contacts['joe']['home_address'] = ''; $contacts['joe']['home_phone'] = ''; $contacts['joe']['office_address'] = 'jsfvkl'; $contacts['joe']['office_phone'] = 'jsfvkl'; b; $contacts['clancy']['home_phone'] = 0123 4567; $contacts['clancy']['home_address'] = 'jkjkjk'; $contacts['joe']['office_address'] = 'jsfvkl'; $contacts['joe']['office_phone'] = 'jsfvkl'; Thanks to everyone who has commented. if you go for option b; you're going to have do a vast amount of isset() checks in a for loop and all kinds of fancy business logic for $contacts['clancy']['home_phone'] = 0123 4567; vs $contacts['clancy']['home_phone'] = ''; vs 'home_phone' not set This question is far less clear-cut than you might assume. The data is actually stored as a text document, with a separate line for each piece of information. To minimise the file length blank fields are simply omitted. When I load the file into memory it is much simpler to enter only the fields which are actually specified. As there are ~600 entries this presumably gives a significant saving in loading time and in memory. However if I take this approach I then have to add an if(isset( ...)) test before I read each field when I'm trying to access a specific entry. This would only increase the memory usage by a very small amount, and would have a negligible effect on timing. So if I fill in all the entries when I load the file it will increase the loading times slightly, and use slightly more memory. On the other hand it will save me from having to think about it whenever I access a variable. The question really comes down to whether the saving in memory if I don't load the empty variables is worth the extra programming hassle when I write new procedures for accessing an entry. so one would guess that code would far outweigh any tiny speed gain from dropping the additional items in the array. on another note; php has been stable and speedy now for a very long time, some bit's like the reflection api could be speeded up a little bit as demand grows, but certainly all scalars and compound types have been tested and optimized to hell and back (afaik). One could reasonably hope that the same could be said for every part of the programming chain, but it is one of the ironies of modern computing that computers get faster and faster, memory gets cheaper and cheaper, programming appears to get simpler and simpler, yet the programs get slower and slower. I have a fairly modern (maybe 2yo) computer, and use XP professional 5.1. Not long ago I switched to Office 2007 12.0, and when I did so I was appalled to discover that if I had a document loaded into Word, and hit Ctrl A, I could watch the highlighting scroll down the screen! As a former assembly language programmer I have some idea of the vast amount of thumb twiddling which is going on behind-the-scenes when I make some apparently simple request like the one to get my phone number. Undoubtedly most of this occurs in the murky depths of the operating system, but if there were any simple way to avoid adding to it unnecessarily it would be nice to know about it. you can test this all you're self, simply populate an array with say 1000 random other arrays of data with 10 keys each, stick it in a for loop and time several times, then do the same for an array as above but with subarrays of only 5 keys; see if you can spot any significant difference. [then compare to say a single database select, or an execution of a small script.] another way of putting it; I'm 99% sure that nobodies code is perfectly optimised enough by itself to notice any performance hits from php; quite sure you could make far bigger gains by optimising you're own code first :p regards! ramble -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Hidden costs of PHP arrays?
On Fri, Jan 30, 2009 at 11:10:16AM +1100, Clancy wrote: snip As a former assembly language programmer I have some idea of the vast amount of thumb twiddling which is going on behind-the-scenes when I make some apparently simple request like the one to get my phone number. Undoubtedly most of this occurs in the murky depths of the operating system, but if there were any simple way to avoid adding to it unnecessarily it would be nice to know about it. Ahhh, finally someone who understands this principle. There's simply no reason to waste cycles if you don't have to. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Hidden costs of PHP arrays?
On Thu, Jan 29, 2009 at 9:02 PM, Paul M Foster pa...@quillandmouse.com wrote: On Fri, Jan 30, 2009 at 11:10:16AM +1100, Clancy wrote: snip As a former assembly language programmer I have some idea of the vast amount of thumb twiddling which is going on behind-the-scenes when I make some apparently simple request like the one to get my phone number. Undoubtedly most of this occurs in the murky depths of the operating system, but if there were any simple way to avoid adding to it unnecessarily it would be nice to know about it. Ahhh, finally someone who understands this principle. There's simply no reason to waste cycles if you don't have to. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Flip side of the coin: also no point in wasting 10 hours accomplishing something that can be done in 2 on a management screen that rarely gets used. :) -- http://www.voom.me | EFnet: #voom -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Hidden costs of PHP arrays?
Clancy wrote: Also what the relative virtues of defining the same set of fields for every contact, as against either defining only the fields which actually hold values, as in the following examples? a: $contacts['clancy']['home_address'] = 'jkjkjk'; $contacts['clancy']['home_phone'] = 0123 4567; $contacts['clancy'][' office_address''] = ''; $contacts['clancy']['office_phone'] = ''; $contacts['joe']['home_address'] = ''; $contacts['joe']['home_phone'] = ''; $contacts['joe']['office_address'] = 'jsfvkl'; $contacts['joe']['office_phone'] = 'jsfvkl'; b; $contacts['clancy']['home_phone'] = 0123 4567; $contacts['clancy']['home_address'] = 'jkjkjk'; $contacts['joe']['office_address'] = 'jsfvkl'; $contacts['joe']['office_phone'] = 'jsfvkl'; if you go for option b; you're going to have do a vast amount of isset() checks in a for loop and all kinds of fancy business logic for $contacts['clancy']['home_phone'] = 0123 4567; vs $contacts['clancy']['home_phone'] = ''; vs 'home_phone' not set so one would guess that code would far outweigh any tiny speed gain from dropping the additional items in the array. on another note; php has been stable and speedy now for a very long time, some bit's like the reflection api could be speeded up a little bit as demand grows, but certainly all scalars and compound types have been tested and optimized to hell and back (afaik). you can test this all you're self, simply populate an array with say 1000 random other arrays of data with 10 keys each, stick it in a for loop and time several times, then do the same for an array as above but with subarrays of only 5 keys; see if you can spot any significant difference. [then compare to say a single database select, or an execution of a small script.] another way of putting it; I'm 99% sure that nobodies code is perfectly optimised enough by itself to notice any performance hits from php; quite sure you could make far bigger gains by optimising you're own code first :p regards! ramble -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
