About efficencies
-
I just talked with a guy who is the CEO of a small company dealing with ERP software.
The expected usage of the software is ~70-80 users.
He went on & on about efficencies and how it is important to be able to do things fast.
Then he dropped a gem: he had fired a programmer that used ASP.Net's
labels instead of coding it up in HTML since the object creation caused
a considerable slowdown.
Anyone can comment on that? It seem ludicrous to me,
-
@Ayende Rahien said:
I just talked with a guy who is the CEO of a small company dealing with ERP software.
The expected usage of the software is ~70-80 users.
He went on & on about efficencies and how it is important to be able to do things fast.
Then he dropped a gem: he had fired a programmer that used ASP.Net's
labels instead of coding it up in HTML since the object creation caused
a considerable slowdown.
Anyone can comment on that? It seem ludicrous to me,
Well, he should have been fired. It's clearly obvious he should have been using JavaScript and XML to do the work.
-
@Ayende Rahien said:
I just talked with a guy who is the CEO of a small company dealing with ERP software.
The expected usage of the software is ~70-80 users.
He went on & on about efficencies and how it is important to be able to do things fast.
Then he dropped a gem: he had fired a programmer that used ASP.Net's
labels instead of coding it up in HTML since the object creation caused
a considerable slowdown.
Anyone can comment on that? It seem ludicrous to me,
Yes, that's ludicrous. While there's a lot of "obvious" things
you should keep in mind to increase performance, object creation time
simply isn't one of them. Premature optimization is the root of
all evil.
This CEO is neither technically nor socially competent.
-
Of course, do the math. 80 users. By not
creating this object the page comes up a couple nanoseconds
sooner. Lets call it 50. Lets assume these users do
nothing else but call up this page all day, and make changes (as
opposed to using the software to make the company money).
Each change takes 10 seconds. Each person is working
a 12 hour day, 6 days a week.
If page loads were instant they could do 2,073600 changes per
week. However adding 50 nanoseconds to load time brings
that number down to 2,073,599.989632! I only
takes 2 years before they have lost one full change (10
seconds)! Clearly it is better to pay a programmer to write
HTML by hand. It would take a good programmer 30 minutes extra to
do the work by hand, which works out to 180 years to break even, after
that it is all money in the bank. But wait, if we assume these
are highly paid upper management ERP users that make 4 times as much as
the programmer (after overtime), that is only 45 years to break
even. How can you loose?
Of course page load times are not instant, so my numbers are not
correct, but you can see the trend. Someone should point
out that instead of a web interface he can get his ERP implemented in
ASICs, which would be even faster, getting the page load time
down to faster than monitor refresh rates. This would clearly save
a ton of money over the next 30,000 years - assuming the software needs
no changes in that time.
-
Absolutely ridiculous.
The object creation overhead for a few labels is insignificant compared with the rest of the application.
I he is so concerned about efficiency, he should focus on the output
caching scheme. Chances are a lot of the pages (or parts) can be
cached, so objects get created far less frequently.
But, is this really what a CEO should be doing?
-
He's right. Once everyone realizes this, the whole OOP fad will be over. <jk>
-
but javascript doesn't support goto.
-
@Ayende Rahien said:
I just talked with a guy who is the CEO of a small company dealing with ERP software.
The expected usage of the software is ~70-80 users.
He went on & on about efficencies and how it is important to be able to do things fast.
Then he dropped a gem: he had fired a programmer that used ASP.Net's
labels instead of coding it up in HTML since the object creation caused
a considerable slowdown.
Anyone can comment on that? It seem ludicrous to me,
Name of company please
-
@hank miller said:
Of course, do the math. 80 users. By not
creating this object the page comes up a couple nanoseconds
sooner. Lets call it 50.
Waiiiiitasecond! Since your whole argument stands and falls with this
number, I'd like to see some justification for that estimate! Looking at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp, it seems to be about right for a current CPU and relatively simple objects, but was that really an informed guess or just luck? And are ASP.NET labels relatively simple? It's a "framework", so seemingly simple actions could in fact cause all kinds of behind-the-scenes activity.
-
@John Smallberries said:
But, is this really what a CEO should be doing?
No, but it's not surprising. After all, he has to be doing something besides playing golf with the board members and customers. [li]
-
@brazzy said:
@hank miller said:
Of course, do the math. 80 users. By not creating this object the page comes up a couple nanoseconds sooner. Lets call it 50.
Waiiiiitasecond! Since your whole argument stands and falls with this number, I'd like to see some justification for that estimate! Looking at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/fastmanagedcode.asp, it seems to be about right for a current CPU and relatively simple objects, but was that really an informed guess or just luck? And are ASP.NET labels relatively simple? It's a "framework", so seemingly simple actions could in fact cause all kinds of behind-the-scenes activity.Lets see... the label has to be created... The page has to be parsed (which it will be anyway, even without the labels). The proper value's are to be inserted for the labels... I think data transport would still take longer than any of this, except maybe for the very first time. But the very first time would be slow without labels too.
On with the labels!
Drak
-
Hey!
You're woring at my last workplace I think.
He worried about the efficency of string concatination using the + (& for you VB users) operator, but wanted to use late binding [+o(] all thru the data model.
-
@dhromed said:
but javascript doesn't support goto.
No, but you can get creative with it to do just that. Like for
example, call functions that you will never plan on reusing, and ignore
their return values, and intersperce them within your code
haphazardly. For instance:
// I'm going to dump everything within "main" and ignore any
// procedural programming or modern techniques and guidelines.
// But since I'm the kinda guy who uses GOTOs, I probably don't
// comment my code either, so ignore this comment.
function main() {
//Do stuff
// Do more stuff
// Do other stuff that will probably won't be called
do_even_more_stuff = new function() {
// find something to do
}
the_end = new function () {
// do some final stuff
}
Goto( do_even_more_stuff );
Goto( the_end );
}
function Goto ( func_ref ) {
call( func_ref );
}
-
@DZ-Jay said:
@dhromed said:
but javascript doesn't support goto.
No, but you can get creative with it to do just that. Like for
example, call functions that you will never plan on reusing, and ignore
their return values, and intersperce them within your code
haphazardly. For instance:
// I'm going to dump everything within "main" and ignore any
// procedural programming or modern techniques and guidelines.
// But since I'm the kinda guy who uses GOTOs, I probably don't
// comment my code either, so ignore this comment.
function main() {
//Do stuff
// Do more stuff
// Do other stuff that will probably won't be called
do_even_more_stuff = new function() {
// find something to do
}
the_end = new function () {
// do some final stuff
}
Goto( do_even_more_stuff );
Goto( the_end );
}
function Goto ( func_ref ) {
call( func_ref );
}
Somebody ought to write a book called "Fatal JavaScript: Things you can
do with JavaScript that will likely result in you getting killed by
your peers"
-
@KissTheCode said:
He worried about the efficency of string
concatination using the + (& for you VB users) operator, but
wanted to use late binding [+o(] all thru the data model.
String concatenation DOES cause gigantic performance problems in many
environments (e.g. Java) when it's used to build large strings in small
increments. It's a one of the standard examples for native coding
leading to big problems. Admittedly, a lot of people don't really
understand this and think it always causes perfromance problems.
As for late binding, it can cause some unexpected delays, but only when
stuff is used for the first time, so it's pretty irrelevant for
performance.
-
@Drak said:
Lets see... the label has to be created... The
page has to be parsed (which it will be anyway, even without the
labels). The proper value's are to be inserted for the labels... I
think data transport would still take longer than any of this, except
maybe for the very first time.
You think that's all that happens - but can you really be certain?
I sure wouldn't bet on it when a framework is involved. In fact, I
would never bet on ANY performance estimation from anyone. The only
really trustworty source of performance information is a profiler. Of
course that also goes for the CEO, but we don't know whether his
distaste for labels is really unfounded or not. It may well be that he
was burned by some app where labels were abused and removing them
actually caused a big performance gain. Of course even then it's a big
WTF to fire someone over it without warning (if that's really what
happened).
