D
dbeavon
Guest
Thanks Brian, Yes, eventually our proxies get large. A couple of them take over ten minutes to proxygen. Obviously that got way out of hand especially given that, when one of them is being generated, only one CPU core is doing work and the rest of the machine is idle. At least when we run our CI builds, the two proxies can be built from two independent OS processes and use separate cores. But there is still some significant CPU capacity on our build server that is not being utilized for the CPU-bound proxygen operation. As you indicated, splitting things into smaller proxies is a good strategy but it only goes so far. We already begin to see performance pains after a xpxg grows to include about two or three dozen proc objects (with related internal procedures and a variety of DS/TT parameters). This pain can involve waiting 30-60 seconds for a new proxy assembly. That may not sound like a lot of time but if you have to repeat that all day long it gets quite tedious and can become one of our productivity bottlenecks. Remember that proxygen needs to be run whenever the DS/TT data structure is changed or any time a method signature is changed (ie. parameters are added or removed). And I would add that in many cases a proxy xpxg is forced to include *all* the proc objects which reference a shared dataset definition - this places a limit on our ability to split things up. Thinking out loud for a minute, it doesn't seem too difficult to imagine a proxygen that would do all the necessary DS/TT work ahead of time, in parallel, and then proceed to do all the proc object work in parallel too. As things work today, much of my machine's CPU is idle while we're waiting for these proxy assemblies to be created. There is a huge opportunity for improvement. I hope I'm not the only one complaining. (Now that PASOE offers other options like REST, it probably lowers the prioritization of proxygen improvements, and it will also shrink the community of developers who are trying to use proxygen. ) Another thought... if Progress doesn't have the necessary developer resources to work on these types of things then perhaps they could open source some of their developer tools such as this old proxygen utility. I'm sure that there are .Net or Java programmers who would be happy to rearrange some of this code and send it to multiple concurrent threads. Nowadays that is a pretty standard thing to do (at least outside of the world of ABL).
Continue reading...
Continue reading...