× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, 20 Jul 2005 21:40:03 -0500
 "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> > From: Brad Stone
> > 
> > Memory is cheap.  Memory is fast.  If that's the issue,
> > then straight CGI (no templates) would be even faster.
> 
> And impossible to maintain.  Otherwise, just code it all
> in MI and be
> done with it.  Man, you argue some weird points.

Impossible.  MI.  Keep using outrageous terms and
comparisons to prove your point, Joe.  

> 
> 
> > In
> > my speed tests I saw no speed differences between
> embedding
> > HTML in the RPG program and with eRPG SDK.  Not even
> with
> > 10000 hits.
> 
> Then your tests aren't testing the HTML generation.
> 
> It's common sense that using a substitution-based
> template language MUST
> take more cycles than a pure hardcoded line HTML
> approach.  You need to
> write the test to test the pure cycles of your program.
>  Make sure
> you're at 100% load on your tests, then compare the
> number of
> repetitions with and without template substitution.

Let's just say the difference was negligable.  I'd be happy
to run them again.  Just let me know what other specifics
you'd like besides 100% load before I do it.    

I could start an app that uses the JVM to easily reach that
100% for 2 minutes...  the HTTP admin instance is perfect
for that (make that 5 minutes on our 170 where I ran these
tests).

But that's "only" startup... nothing else...  I mean,
switching from page to page in the admin server taking 2
minutes... that's negligable.

> 
> This stuff about "10000 hits" means nothing.  EVERYTHING
> is fast on a
> machine that's not maxing out.  The question is what will
> max the
> machine out, and how much does your template language add
> to the
> overhead at that point.
> 

Ok..  let's make this simple.  Hits do mean something
because App A may take 2 seconds, and app B may take 10
(500 hits).  If you have a busy site, I know I'd rather
take app A because I don't want my CPUs eaten up.

HEre's a straw.. reach again.

> 
> > No overhead from a JVM involved.  No extra sockets/data
> > queue/etc traffic involved for data access.
> 
> The overhead from a JVM is almost entirely at startup
> time.  Said
> overhead becomes negligible after a servlet is loaded,
> and actually
> becomes less as the UI (the JSP) gets compiled to machine
> code.
> Eventually the servlet will outperform the RPG.
>

Bullsh*t.  Even you know that (but I'm sure we'll hear
differently).  Especially for each job that starts to
handle more jobs... which means another JVM startup.

You first say they're close in performance (JSPs being a
little behind), then that a servlet (I thought we were
talking JSPs) will outperform...

> I agree that there is overhead at the JVM/OS boundary.
>  The overhead
> from a data queue is not zero.  But the iSeries is built
> on data queues
> and it does them very, very well.  But the fact that my
> HTML output
> routines are comiled to machine code will make up for
> that in the long
> run, I think.
> 

So, memory is slow (template storage), but JVM and Data
Queues are not.  Nice condradiction.  

> 
> > So?  Then you're supporting 2 machines and 2 OSes.
> 
> The point is that I CAN do it if I want to, you can't.
>  You can't do it,
> Brad.  Not for less than $10,000.

No, the point is I don't need to.  Only those network
admins that fell it's necessary or want something to do
NEED to do it.

> 
> 
> > And for
> > $500 you'll get a really nice Dell with a CRT montior
> and
> > an 80gb hd, 256k memory.  Hardley enough machine for
> any
> > real traffic, especially now since you've added more
> > traffic at the cable level between the machines.
> 
> You might want to check out the world outside of Dell,
> dude.  For $500 I
> can build an absolutely SCREAMING Linux/FreeBSD box with
> 1GB of memory
> and a fast, fast processor that will handle just about
> anything short of
> eBay.  Seriously, what do you consider "real traffic"?

Ya, dude... like I really seriously meant Dell is what you
wanted to buy.  Get real, man.  Quit arguing crap like this
to try and prove a point.  Your "screaming" linux box is no
more powerful than a $500 Dell.  I've built and bought
quite a few PCs... and these days you don't save much
building over buying...  

> 
> Box: $50
> Motherboard w/NIC: $70
> 80GB Drive: $70
> 2.8GHz Celeron: $90
> 1GB DDR400 RAM: $180
> Total: $460

Pricewatch.com rules.

> 
> $30 gets me 1GB LAN.  For another hundred bucks or so I
> can get more RAM
> or put some L2 cache on the processor.  I might have to
> spend another
> $50 on an old monitor if I don't have a KVM switch.
> 
> 
> > I would be happy to name my procedures the same as
> CGIDEV2
> > or others, but there are subtle differences in my
> > procedures and how they function with the product.
> 
> Thank you for making my point more clearly than even I
> could have.

Your sarcastic statement here proves nothing.

> 
> 
> > I also
> > wanted to give them "more descriptive names".  You can
> > always rename them in the prototype definitions if you
> > really want to standardize them...
> 
> This is grasping at straws, man, especially if there are
> parameter
> differences.

Ha...  the kettle is black.

> 
> 
> > > Those are the most glaring architectural deficiencies
> of
> > > the RPG-CGI approach.
> > 
> > Glaring to some, far fetched to others, meaningless to
> > others (those who could give a ratt's *ss or understand
> > it's "just HTML" and the delivery mechanism isn't all
> that
> > complicated).
> 
> The inability to move your UI into the DMZ is not "far
> fetched" or
> "meaningless".  If you don't need it, then it's not
> relevant from a
> business standpoint, but nevertheless it's an irreparable
> deficiency in
> the architecture.

So that would mean that because I don't need to access DB's
natively in JSPs/Java but I may want to, it's a flaw in
that architecture?

> 
> This is not some touchy-feely "everything is okay"
> Microsoft seminar.
> Some designs are really better than others, and JSP is
> better than
> RPG-CGI.  That doesn't mean that RPG-CGI is wrong for
> some situations;
> sometimes a dumb tube is better than a PC. 

Ya, and we RPGers are still not flipping burgers.  Again,
your comparison here has nothing to do with the facts at
hand... it's all opinion.  Calling RPG a dumb tube and JSP
a PC means nothing to anyone except those who can't think
for themselves.  It also doesn't prove your point.

I quicky grow tired of this Joe...  Time to play poker and
forget I even replied the first time knowing what would
happen again.. 

Brad

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.