Unfortunately, there's no good solution I can recommend right now to make the emitted MarshallerFactoryImpl smaller.
We do have plans to change the way we generate marshallers in Errai. The idea is to generate one separate marshaller class per portable type. Together with incremental generators this should result in a big performance improvement in DevMode and also allow for code splitting. Similiar to the @LoadAsync support we have for IOC (the generated BootstrapperImpl), marshallers could then be partitioned into different split points and the corresponding code could then only be downloaded when needed (in smaller chunks).
I just did a quick round of compile reports on some of our demos and they average a lot lower than 2KB per property. So, there mioght be a specific case that can be optimized. Could you maybe share one of your marshallers? Maybe there's something we can do in the short-term.
Thanks for your quick respone.
We doesn't use any custom marshaller, i have attached the generated MarshallerFactroyImpl.java, i hope this help.
I tested the difference between 2.2.0.Final and 2.4.0.Beta1 Marshaller. The good thing is ... in 2.4.0.Beta1 the generated Marshaller is significantly smaller, but unfortunately the rpc's in 2.4.0.Beta1 are even slower.
1 of 1 people found this helpful
-Derrai.compile.perf.perform_reachability_analysis=true activates Errai's own reachability analysis which isn't ready for production yet. The motivation for it is that our MarshallerFactoryImpl brings in all portable types and GWT's own reachability analysis can't eliminate these types.
Thanks for sharing your marshaller output. I don't see any pathological case in there. Good thing the marshallers are smaller in 2.4. RPC's should def. not be slower though. We will look into this.
Thanks for your help and effort!
When the 2.4.0 version becomes final, i will try to migrate our project.