Re: Confirm my Performance Test Against Java?

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/.
>