Blog
Ibuildings Blog
 |
Ibuildings |
Friday, 12 February 2010Productivity in PHP from a fun perspective
One of the reasons so many people choose PHP for their web development is that it's fast. Not necessarily in the gazillion-requests-per-second sense, but in terms of developer productivity. One sentence you'll hear me say regularly is: "PHP is not pretty, but it gets the thing done, and gets it done well" and even in my 'PHP in the Enterprise' evangelization, the productivity argument is one I often use.
Every once in a while things happen that prove this point, and this is a post about such proof. Last week, a bunch of people from the PHP community including myself visited Sogeti's Engineering World, where Ian and Felix did their 'Document Classification in PHP' and 'High Gear PHP' talks, on a technology-agnostic conference that was focused on software engineering in general.
(Ok it wasn't so much about software engineering, it was more about development tools and dealing with legacy systems, but we had a fun day nevertheless.) At the conference there was a coding contest. Contestants could team up and had to write an application that found the shortest route through an arbitrary maze. To be able to test all entries under the same conditions, the solution had to be supplied as a web service that supplied a given API. It wasn't until the second to last session during the conference that Juliette, Erik, Ian and Felix decided to not go see a talk but to attempt the contest. A little while later, they had a working solution, and though they knew they would be unable to win as they were past the deadline, they didn't play for the win, they played to show off PHP, to a crowd mostly consisting of traditional technologies (Java, .NET, Oracle, Cobol even). The results were shocking. Of course most teams found the right solution to the problem, as it's not a particularly hard algorithm to solve a maze. It's how the contestants got there where the differences were striking. Here's a table with some data:
There were 2 other teams that competed but they didn't submit a final solution. Someone mentioned that the Java solution performed its task in only 17ms, but there wasn't any proof nor numbers to back that up. What's interesting is the huge differences in development time, and lines of code. According to Buzzle, about 10.000 lines of code can be handled by one full time software maintainer. That means that the .NET team would have to hire a guy to maintain this application, the Oracle people would spend 5 weeks a year on maintenance, and the PHP team would only need 4 days of maintenance. Another unscientific conclusion: with PHP you can get results more than twice as fast as with .NET, and more than 3 times as fast as with Oracle. If you use Java, you'll never get to a solution.  What about runtime performance? We know PHP isn't the fastest language, and in particular for algorithmic applications where CPU crunchtime is important, PHP wouldn't be the ideal choice if you care about performance (as would any interpreted language probably). Still, Ian mentioned that there was no optimization in the algorithm done so far, and given an extra 15 minutes, he could probably get the speed down to near 2.5 seconds, more even with more time. But the team chose to prove a point in productivity, and they made an excellent case. Ok, granted: this is a contest and I'm writing this for fun. No claims should ever be made based on the contents of this post: this isn't a scientific measurement (far from it), so you have to take the above with a large grain of salt. It's still fun to see and share those results though, and that was my goal. Team PHP: thanks! Share         Trackbacks
Mit php lässt sich schnell entwickeln
Hiho, auf meiner reise durchs netz bin ich über den Blog von Ivo Janschs gestolpert der dort seine erfahrungen zur Engineering World 2010 kundgibt. Dort gab es dann auch etwas was mein interesse geweckt hat nämlich einen “Coding Wettbewerb”...
Weblog: BlackDays
Gevolgd: Feb 15, 19:36 Reacties
Geeft reacties weer als
(Lineair | Samengevoegd)
QUOTE: Another unscientific conclusion: with PHP you can get results more than twice as fast as with .NET, and more than 3 times as fast as with Oracle. If you use Java, you'll never get to a solution. Fuck yeah!
The more you work with java and top vendors the more you appreciate PHP. It is really a great tool if used properly.
Respect to the PHP community!
Thanks for the nice write up Ivo !
And yes, you're right, we didn't go in to win, we went in for the fun of it. We hadn't realized in advance how little time there was left to participate, but didn't really care either. The rules were a bit unclear about whether runtime or development time was the criteria to win anyway. On an additional note: if they'd had a running count of amounts of laughs shared between team-members, we would have topped that chart  Still, credit where credit is due: Oracle did their coding as a team, but .Net was a one-guy show, so kudos to him for productivity (& winning of course).
Yes it would be nice to add a column with the number of people in each teams.
What a piece of $%&/()!
A experienced .NET developer had done this in under 1h.
Of the 8680 lines of code about 250 lines were needed for calculating the solution. It includes a bunch of lines for a generated webservice proxy, and also some test code. Of The 250 lines, about 150 lines consist of empty lines and lines with only { and } characters. Even the remaining 100 lines 'real' code were not even close to being written with least amount of code.
Also, when 4 persons work on the problem for 1,5 hour would equate to 6 hours of work to come up with the solution. So in the end, it seems to me that you would lose both on time and on lines of code. But I agree that it would have been interesting if the contest would have included lines of code / maintainability / time used to develop as winning factors. Hope to compete with you again in the future, because it indeed is fun!
I don't think any conclusions can be taken from this coding competition, too many variable factors
But for posterity, we (the PHP team) implemented just a simple depth-first search, without route caching or any other sort op optimalisation. I think the guy's who organised it, who quoted the java solution being 17ms implemented Floyd–Warshall. But I'm not 100% sure. Anyway, the fact that multiple teams each chose different solutions means that execution speed, while being the winning criteria, can't be used to also compare language speed. Also on the development speed there will be differences, because Ian and I both had some experience with implementing pathsearching algorithms. I would imagine that if some team did not have this experience they would have a serious handicap for development speed. Anyway, It's a great bragging statistic, but nothing more then that really The most important point was that we had a blast doing it.
Do you have the original problem? I'd like to have a go too
.
The problem was quite basic:
Connect to a certain URL using web services and get a string from it The string is a 128x128 char maze. All lines have been concatenated (sp?) together. The maze consist of the following chars: # = hedge . = pathway S = Start point (normally found at the top, but always on an edge of the grid) F = Finish point (normally found at the bottom, but always on an edge of the grid) 1, 2, 3 ... 5 = way points anywhere in the grid. You have to touch these in the correct order on your way from S to F Connect to the same URL as before to submit your solution as a string consisting of directions (N = North, E = East etc) to walk through the maze using the most efficient path * Each connect you would get a different maze The URL was one on their local server, so I can't give you that (and I presume I would be offline now anyway).
Don't mind the bolding - I had put astrixes as bullet points, my duh.
Seeing the PHP execution time makes me wonder how much something like HipHop would help for making algorithms in PHP. I have always avoided it because of how slow it is. PHP just wasn't made for heavy computations - but like you said, it lets you solve the web problem very quickly and very well.
I am a php guy - but the comparison does not make much sense.
1. The problem implies knowledge of algorithms such as Dijkstra and Floyd-Warshall, so it is focused on the programmers ability. 2. The .NET programmer was alone versus 4 php developers. 3. He wrote 8000+ lines in 3 hours, running the numbers is a line of code every two seconds. It means much of his code has been generated. 4. One person can maintain 10K lines of what? Compare assembler, Php and bad written Php. 5. The .NET developer wrote TESTS. The php lines count indicates that it is probably a single script, with no object-orientation or unit tests. And the ability to verify regressions only by connecting to the real server. |
