Re: Confirm my Performance Test Against Java?



[Note: parts of this message were removed to make it a legal post.]

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



.



Relevant Pages

  • Re:Urgent requirement for Java developers.
    ... Identifies key business and technology drivers that impact application ... and application design, coding and design standards, best practices, ... application of techniques and standards such as service-oriented ... Expert level on Java J2EEdevelopment knowledge (5+ years on J2EE ...
    (comp.lang.java.beans)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... These rules provide consistency in design, ... The RM constraints are fine and necessary, ... should be *forced* on developers that sets me off. ... I think it is just because he feels that java is ...
    (comp.object)
  • Re: Searching OO Associations with RDBMS Persistence Models
    ... These rules provide consistency in design, ... triggers and some embedded language quite limited. ... should be *forced* on developers that sets me off. ... I think it is just because he feels that java is ...
    (comp.object)
  • Full time opportunity in NY for core java developers
    ... Java Core Developer for the Client team ... Our developers have big ideas and well-written code. ... design of the backend of the client and internal tools. ...
    (comp.lang.java.programmer)
  • Building C# Enterprise Apps
    ... enterprise tools written in java that allow developers to code and deploy ... These tools are designed for developers. ... will click on a button that will compile and save the code, ... Are there classes in the .net framework that faciliate this type of design ...
    (microsoft.public.dotnet.languages.csharp)