On 03/02/15 14:03, Andrea Faulds wrote: > But I don’t consider 0.25MB extra to be such a problem in practice. The PHP > binary is already huge, and every system running PHP will have ample memory.
Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ... they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming an option so I don't have to program in C or something else, and then we look to strip everything that does not need to be present. Only support one database interface. Ideally have simple unicode direct in the core and magically the 'already huge' binary becomes an option so code developed on the servers can be run locally, and only the data needs to be sourced over the network connection. The trade off is battery life over optimised code ... it even helps where a network connection may be down more than up and it does not need all of the current overheads to work. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
