You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In ConfigurationProcessor#registerConfigs(), we push the config properties/doc to the Dev UI through a call to a recorder method.
While this is a nice idea, it actually has quite a high cost: in a simple example with only a few extensions, I end up with a recorder method that is quite large (3 MB+).
I wonder if we should try to improve that once we have saved the config doc into a structured file inside the extension jars.
That being said, the deployment jars are not available once the Dev UI has started so not sure loading things lazily will be doable, and we might end up with a very similar issue (except maybe avoiding the overhead of the recording data structures, which might actually be a significant win).
seems like we could just lazily load from the deployment jars as we could assume local maven GAV's are available....might even also work in remote devmode.
@radcortez FWIW, I started working on that one again. Instead of rewriting everything, I will try to work more in baby steps as it's definitely in the way of several improvements to the build.
Once things are properly isolated, we could think of moving some things to SmallRye Config and iterate from there.
In
ConfigurationProcessor#registerConfigs()
, we push the config properties/doc to the Dev UI through a call to a recorder method.While this is a nice idea, it actually has quite a high cost: in a simple example with only a few extensions, I end up with a recorder method that is quite large (3 MB+).
I wonder if we should try to improve that once we have saved the config doc into a structured file inside the extension jars.
That being said, the deployment jars are not available once the Dev UI has started so not sure loading things lazily will be doable, and we might end up with a very similar issue (except maybe avoiding the overhead of the recording data structures, which might actually be a significant win).
This is related to: #38814 .
The text was updated successfully, but these errors were encountered: