[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Thu, 12 Nov 2009, tom wrote:
Gordon Henderson wrote:Your program is too 'small' to need this sort of thing. However if you plan for world domination in your code, being able to run a large amount of it on one server rather than 10 can make a huge difference. You may find you upgrade the RAM on the MySQL server, put the necessary tables in it and the bottleneck becomes PHP.On Thu, 12 Nov 2009, tom wrote:One thing that never ceases to amaze me was that the .NET/CLI languages concept of a standard variable set definition shared across multiple languages so that any language could interact with any other, has never been fully taken up elsewhere. I even tried to get the .MONO crowd to allow multiple languages to be used in a single class before I gave up .NET.Hm.. I've no experience of .NET, but way back (like 25+ years back), I was linking FORTRAN and C programs together (as well as Pascal and assembler) on both Unix boxes and (spit) Prime minicomputers.However PHP can talk to C and C++ and other compiled languages and is not bad for testing out ideas that can then be hardwired in a compiled language when pretty static to speed things up.I've never had the need to re-write a PHP program into something faster. My entire VoIP billing and invoicing system in written in PHP - some of it is web facing, some command-line (or batch-file driven) Most of the time they are waiting on MySQL, or writing files, so re-writing them in C would be of little benefit.
Maybe. But right now it isn't.
The .NET reference was due to the fact that all types are shared across all languages so you can pass an array of long integers from C# code to VB# and not suffer data loss or corruption, or have to mess about with it to get it to fit. You probably discovered this problem linking FORTRAN/C and Pascal - there are massive marshalling libraries out there to try and help with this -I've even heard that that was one of the reasons why XML was born
That's not been my experience - certianly not with mixing FORTRAN and C. I can not imagine anything more horrific than taking an array of data in C, converting it into some textual XML representation, calling a FORTRAN subroutine which would then convert it into binary data again, process it, then convert it back to XML for the C code to manipulate again.
There is some pretty innefficient (and insecure!) PHP code out there though - however most of the active (and commercial) projects are getting a lot better - e.g. vBulletin - I have one (dual processor/4GB) server dedicated to a vBulletin board and it's stupidly busy, even with the Zend optimiser thingy working on it too.
Have/can you profile it to see whats holding it up?
I could, but can't be bothered. The customer gives me money, I make sure the server has a degree of Internet connectivity and functionality and we're both happy... If they want it to go faster they can pay me for my time to look into it, but right now it's ticking over nicely.
Gordon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html