jongpau
Member
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.
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.