Is your OpenEdge Application severely obese too?

[jongpau]

Hi All,

First of all, it's been a while since I have been around on ProgressTalk for which I cannot give any other excuse than that I have simply been too busy to actively participate on the forum. I suppose that's how these things go sometimes. Please don't take this post as a one off, I will try toactively participate in the forum again

At my work we have run into a bit of a snag with the size of the rcode that is generated in version 10. A couple of years ago we converted our application from version 9 fat client to OE10 using AppServers. In itself this all worked fine and we are quite pleased with the result, except for the fact that our rcode has grown from around 130MB for the full V9 fat-client application to over 515MB (compiled with min-size) for the client rcode only! Yes, of course we are now using temp-tables but these only account for a small part of the growth in the rcode size. Mind you, simply compiling a .p with a single temp-table and nothing else already causes a 6 fold increase between version 9 and 10. Some tests with compiling a simple program with just a few lines of code also show a drastic increase in rcode size. An interesting observation was that some pretty prominent people from Progress USA were not even aware that the rcode had grown so much between version 9 and 10 and confronting them with this fact caused some jawdropping.

I realise that 500MB is not that much for a modern application (the software running on my iPhone and MS Office is probably around that size too) but we have a huge potential in our market for cloud deployment, saas, application virtualisation etc. We simply do not have the time to redevelop our client into a (near) zero footprint implementation - that would take years. Yes we can do some work in our application by getting a bit smarter in how we do things and moving some stuff to the AppServer but really we have to lose about 60% of the bulk and we won't get that far by being clever (I think we can maybe make a 20% change, 30% tops). Calling upon Progress for assistance has lead us to nowhere other than the answer "It is the way it is and we can't do anything about it. Oh, in version 11 the rcode might get even larger still". We had hoped that maybe some compiler switches could be added to exclude any new OE functionality we don't use such as OO, .Net etc, but that is like asking the government to stop raising taxes.

So, finally I get to my real question here (thanks for reading this far)... Has anybody else experienced the same rcode size growth? How have you gone about handling this in your WebClient deployments? Have you been in touch with Progress about this and what is your reaction to their indifference (assuming you had the same reaction as we did)? Does anybody have any helpful hints and tips that can help us lose some serious weight? Do you use WebClient to deploy in a saas model and how do you go about it? What are your experiences with these kind of things in general? Really, anything useful is appreciated.

 

[MaximMonin]

When i did web project with many small procedures called from WSA I noticed that any module with 50 lines compiles to 5k r-code or 200-300k r-code.
200k+ was when I included {system.i} at the beginning of module to use my shared variables and temp-tables.

To reduce a size of code i tried to exclude {system.i} from any module that doesnt use any shared variables in my project.

 

[TomBascom]

Why does the size of the r-code concern you?

Is it because it takes longer to download a webclient? If that is the concern have you tested it to make sure that the concern is valid?

Assuming that your concern is along those lines and that it is a real problem... can you do something similar to what you've suggested Progress do? I.e. remove unnecessary stuff from your package? Or at least the initial download. Most applications have a lot of features and functionality that are only rarely used. Could you defer download of those aspects until later? Or download them in the background while the app initializes?

What about compression? I have two thoughts there -- one is to make sure that your web server is configured to use compression. The other is to encourage Progress to use compression of r-code. CPU power is cheap and freely available. Bandwidth is the scarce resource. Compression is a natural fit.

 

[tamhas]

I certainly wouldn't reach any conclusions based on total r-code size. As Tom says, the thing to ask is whether you empirically have a performance problem ... and that will be because of the size of individual modules, not the total.

 

[sdjensen]

I did a small test with the follow fancy program

Message "hello World" view-as alert-box.

Size for .p file was 40 bytes
r code (Progress 9.1A) 665 bytes
r code (OpenEdge 10.2B04) 983 bytes (with min-size=true 851 bytes)

Not all people have a fast internet and I would think twice about downloading a 500mb file.

 

[jongpau]

Hi All,

Thanks for taking the time to answer

Yes, we are sifting through our code and cutting out "fat" , replacing some re-ocurring code with more generic code in super procedures so it can be re-used and more such things. But, as I said, the expectation is that we will reach a 20%-30% size reduction max. No matter how you twist or turn, the size of every .r in your application has increased considerably between version 9 and 10 and this has made our intended lean client very very obese indeed.

Indeed, not everybody has fast internet connections and in our market investing in the latest and greatest hardware and super fast internet connections to keep up with the times and demands is not a thing you can just count on happening. Also, our application needs to be able to work not just in the city but also way out back away from big cities where affordable and fast internet is generally not available (yet).

Of course one of the suggestions is to rewrite (part of) our UI in some different zero-footprint technology. Yes we are looking in this area too but everybody knows that this will take a lot of time, effort and cost. Rewriting the entire UI is not realistic anyway as it will take far too long. Progress being who they are trying to flog their latest baby (and possibly next problem child??) Savvion -- has anybody gone down that road??

We have made the initial download for webclient as small as possible but as soon as a user "touches" a function more downloads are required. Yes, we can possibly do work in the area of the webclient package, move from module based cab files to more functional ones but I am very hesitant to make changes in this area. For one thing managing webclient packages is hard enough as it is with the available tools. Trying to add more complexity makes this a lot more difficult and extremely time consuming. Also, changing an established webclient package is not advisable, moving rcode from one cab to another can have very unpredicatble effects - we have had many .rs suddenly vanishing from a perfectly working install by moving them from cab a to cab b. When asked by Progress we have suggested a host of improvements in the area of the WebClient packager and installer/intellistream but I am not holding my breath for Progress to do anything about that - after sending these through it has gone very very quiet.

Anyway, for now we keep chipping away at making improvements on our side.

Thanks again to all who answered and more hints, tips or ideas are always welcome. Again, I would also like to know if anybody here has started using Savvion and what their thoughts are about the product.

 

[Marian EDU]

Not having any experience with webclient packaging one thing it would help is compression, if that's available use it if not start asking for something like that

As for zero-footprint technology, really there isn't anything like that... to get a real application working in the browser is possible nowadays but the bandwidth requirements will probably go higher than the web-client implementation you have now, the amount of java script client-side code can grow up quite significantly and even if AJAX data-only requests saves some bandwidth as compared to full page refresh that we used to have in web application until now the bandwidth requirements are probably higher than a regular client-server (fat client or web-client).

IMHO BPM solutions aren't really suited to build real applications, the user interface capabilities are not as rich as one might expect from a business application... it's great for what it does, but it definitively isn't a development environment

If you want to see how a BPM solution looks like try Bonita BPM, it's very much what you'll get from Savvion and being open-source you can take it for a ride to see how much you enjoy it before committing to anything... what you'll get is a workflow engine that can call 'services' and you can mix automated tasks (web-service calls, database updates, send emails, messages, print reports) with tasks that requires user interaction like approving an invoice, select an offer from a list and so on... for user interaction it will generate standard Java web-interface (mostly JSP).