Community
Participate
Working Groups
We are running both JSGenerator and DevJSGenerator whenever generation is needed for client code. However, the output of JSGenerator is not used until we deploy the application. While developer uses VE design, preview, external browser, or debug a handler, we always uses the output of DevJSGenerator. Given this, we should consider to run the JSGenerator when user deploy the application. This could save 50% of JS generation time.
I updated compiler preference file manually to remove JSGenerator, and only keep DevJSGenerator. Then tested by building a rui + service + database application from beginning. Things seemed to be working fine in VE and debugger. There's one time I see some dojo not defined error when debug this application, but it does not appear again when I retried it.
Tony, I agree that disabling the JS Deploy Generator should not have an affect on the development of Rich UI applications, but this would only be a realistic change if we could figure out how to incrementally generate the parts being deployed. I believe we discussed this in the past, and could not come up with an easy solution, but maybe things have changed since then. To be specific, when a Handler is deployed, only the parts that have been changed since the last deployment should be generated, and not all of the parts being deployed. Assuming we can locate the IRs of all of the parts being deployed, and the previously generated content for each of those IRs, I am guessing that we could check the time stamps on the files to see what needs to be regenerated. In general, this feels like something we should investigate after .7 is delivered. Along with the issues described above, there might be issues with synchronizing the generation and the deployment of the .js files, etc. I think it would be better to look into our constant downloading of multiple runtime .js files in the VE before looking into this issue. One thing that might be worth looking into for .7 is to verify that the WorkingCopyGeneration that occurs for the VE is only running the Development generator.
Brian, incrementally generate the parts being deployed seems to be a difficult thing, we could not leverage eclipse in this scenario. The other options to think might be a. Re-gen everything at deploymen. This certainly makes deployment much slower. However, it is a tradeoff between dev performance and deploy performance. If in the real world, users are in dev mode 95% of their time, then a few minutes deployment might be acceptable. b. On top of solution a, make our widgets project configured with both JSGen & DevJSGen so that widgets don't need to be re-gen at deployment time. Make any user created project configured with DevJSGen on, and we will take care of generating the runtime JS during deployment. after all, I'm with you that this discussion can be deferred after 0.7. I have checked WorkingCopyGenerationOperation, it is using devJSGen only.
One thing to think about post-0.7: At deploy time we already have a list of all the dependent IRs for the current handler. For each dependent IR we could look up the corresponding .egl file and check its timestamp vs the timestamp of the generated file (we already have a way to get the generated file's path). If the generated file doesn't exist, or it's older than the .egl file, then generate it. This would cause files to only be generated when they're needed for deployment, without the overhead of always generating everything.
With the performance enhancement in IR Visitor and bug fixes in IDE core (which prevent unnecessarily rebuilds), generation performance does not seem to be a big problem now. Considering the complexity and small benefit of this enhancement, we may want lower the priority and defer this.
I agree with Tony. We can make this a higher priority if we find that it becomes a bottle neck.
