From: Peter Booth Date: 2009-08-25T03:43:37+09:00 Subject: Re: Confirm my Performance Test Against Java? --Apple-Mail-1-101788221 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Ben, I think the problem is that we are technologists, so we see our work through a technical lens. But developing systems is a human activity. On Aug 21, 2009, at 6:09 PM, Ben Christensen wrote: > Peter, > > Taking your experiences one step further, wouldn't it stand to reason > that if a system is being "rebuilt" with all of the lessons learned, > but > with the mature "faster performance" language, that it could achieve > higher performance than being rebuilt in a new, less mature, "slower > performance" language? It wouldn't be true, but it might stand to reason. It would be reasonable for me to expect that Microsoft Word, on my Dual Core MacBook Pro should be 100x as responsive as the first dedicated word processor that I used 25 years ago I think that, in general, systems are as slow as is physically possible whilst still being "good enough." I suspect that the 2 or 3 orders of magnitude degradations are common today because of current hardware, and that 20 years ago the same systems might be 1 or 2 orders of magnitude slower. > > Your well-founded arguments suggest that many (if not the majority of) > performance issues are in poor design and implementation - not the > language itself. I agree that this is often the case - I find and fix > many of them in the systems I profile. A recent example was an issue > causing 2 orders of magnitude in performance degradation because of > absolutely horrible design - nothing to do with any type of language, > platform or infrastructure. My work has shifted in recent years from development to more short-term, fire-fighting, performance work. I've found that to making a dramatic performance improvement in minimal time requires being willing (and able) to work at all layers in the technology stack, from web page construction, application code, server configuration, physical architecture(what runs where), DB schema and query tuning, OS kernel tuning, TCP stack tuning, RDBMS, physical network, hardware, hosting, virtualization, etc. Unless I'm feeling jaded, I wouldn't say poor design and implementation - rather incomplete or nonexistent design and physical architecture, and flawed implementation. A positive spin on this is to say that 95% of startups fail, 70% of IT allegedly fail, thus it's a waste of effort to unnecessarily invest this time until there is evidence that the system will live. > > But if a system is being built by a team capable of achieving the > performance gains you claim with a "slower" toolset, if given a > "faster" > toolset, would that same team not accomplish an even better performing > end result? Not at all. The same team that builds a web service that responds in two seconds is capable of building the same web service with a response time of 200 ms. But what incentive do they have, if they don't have a 200ms SLA? The "bloat factor" is not a measure of developer strength. It seems to be more a function of the expected performance, and how visible performance is. Here's an example: I worked on a project that had more than 100 developers building "portlets", tiny portal widgets that built a single piece of content. My team was responsible for performance. After a few months of furiously tuning everything we could we made a change that had a profound impact: We reconfigured the integration instance of our system so that any user would view the build time of each portlet, as a small label on the frame of the portlet. At first build times ranged from upto a few seconds. Within a few days those developers whose code was especially slow were proactively asking experienced architects to help them fix performance issues. Within two months there were no portlets building in more than 100 ms. The force of social disapproval had a much bigger impact than buying ten licenses of a Java profiler. > ... working with Ruby ..... is not so different from Java ... make > me feel > something earth shattering has occurred. I was a bad/intermediate C++ programmer when I learnt Java. My managers, who were all much stronger at C++ would say similar things. Java did turn out to be ground-breaking despite looking visually so much like C++ The significance of a technology change depends upon how its used, not just syntax or the obvious feature-set. I think it took more than a decade to clearly see how Java had changed things for developers. In 2015 I will be happy to discuss whether or not Ruby makes the earth move for me. > > Thus, if a team equally skilled in both Ruby (and its "way" of doing > things) and Java could approach a project and avoid the design > pitfalls > that cause most of the performance issues you have stated - then > wouldn't the team accomplish higher performance with Java? No. Like the guy in the bar said, "If my auntie Velma had a pair, she'd be my uncle ..." I interviewed with two competing, secretive, equity option dealers in 2004. Each had a team of 3 or 4 developers who had written their own automated trading system. These dealers competed head to head and used identical technology (Java, Linux on Intel), and both were successful. The first place had identified that equity options was an important business to them, knew that the US markets would be most profitable, and had provided the group with almost a blank check to get the job done. They were proud of their 300 server cluster and the profits they made. The other team was less optimistic and had a much smaller bankroll. They didn't realize that the US was the place to be so they tried to deal in all global markets. They built a similar system to the first group but they had a system workload that was about 10x that of the first company. They were just as proud of their home-grown system, which made them lots of money, even though it was hosted on a mere 4 servers. Two teams, similar background, built near-identical systems, and one had a capacity that was 1000x the capacity of the other. This is not unusual. Peter. > Ben > -- > Posted via http://www.ruby-forum.com/. > --Apple-Mail-1-101788221--