|
> From: David Morris > > Java can run at near the speed of RPG. It really depends on where the > bottleneck is. For example, using EJBs to do aggregation over large data > sets will perform poorly compared to RPG -- likely 20X's more > CPU/memory. Java using SQL aggregation to objects will be close enough > to the same performance and probably OK -- likely 5X's more CPU/memory. > Java using SQL aggregation to process that same data without persistent > objects will be very close to RPG -- likely 2X's more CPU/memory. Actually, I don't consider aggregation to be the primary work of a business application. As I understand it, aggregation is queries, and you're right, queries can be cleaned up by moving more and more of the request to the SQL engine. I am a little unclear on how you use SQL aggregation over non-persistent data. Where is this data stored? How does the SQL engine get at it? Are you basically caching tables in memory and letting SQL run through it? In that case, it had BETTER be fast. Anyway, from an application standpoint, it's still been the case that real world enterprise-level business logic (the kind of thing where the logic flow is determined by database switches) is best served by RPG. SQL, regardless of the flavor, doesn't cut it in an environment where you need to check different entities for condition flags, which is the meat and potatoes of any sort of business application. > Java > to call RPG still has to convert the RPG result to Objects, which has > some overhead over pure RPG -- likely 1.5X's more CPU/Memory. In a proper design, the primary overhead is in translation to output Strings. I suppose if that 50% becomes a problem, you can use the %editc BIF to edit your numeric data and then iconv() API to perform your String translation (that will reduce a lot of your CPU requirements). Joe
As an Amazon Associate we earn from qualifying purchases.
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.