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
This is likely somewhat related to #1616, or rather #1616 could be addresses as part of a fix for this. It seems that the initialization of a Structure is extremely expensive.
For example, the NuProcess project has a structure like the following:
And millions of these structures get created/destroyed per minute of execution.
In a profiler, the initialiation of the super class Structure shows up very high. In particular, the calls to validateFields() and initializeFields() are very expensive:
But given the static nature of Structures, it seems like all of the work done in validateFields() could be cached such that all of the heavy java.lang.Reflection work does not need to be performed for every new instance of that Structure. The fields are not changing and therefore "validation" does not need to be continually performed.
Am I correct?
Or does the fact that layoutChanged() exists imply that may not be so? Then again, that only appears to be the case when a TypeMapper is in play, so maybe caching would still work in the case that TypeMapper is null.
Similarly, initializeFields() calls getFieldList() which performs a boatload of reflection on fields that cannot change dynamically, and it does this for every instance construction. Using a cached field list would certainly cut down on the contention reported in #1616 while greatly speeding up the code.
Again, is this a valid observation? If these are valid observations, I will happily submit a pull request addressing these two issues, awaiting feedback here.
The text was updated successfully, but these errors were encountered:
This is likely somewhat related to #1616, or rather #1616 could be addresses as part of a fix for this. It seems that the initialization of a
Structure
is extremely expensive.For example, the NuProcess project has a structure like the following:
And millions of these structures get created/destroyed per minute of execution.
In a profiler, the initialiation of the super class
Structure
shows up very high. In particular, the calls tovalidateFields()
andinitializeFields()
are very expensive:But given the static nature of Structures, it seems like all of the work done in
validateFields()
could be cached such that all of the heavyjava.lang.Reflection
work does not need to be performed for every new instance of thatStructure
. The fields are not changing and therefore "validation" does not need to be continually performed.Am I correct?
Or does the fact that
layoutChanged()
exists imply that may not be so? Then again, that only appears to be the case when aTypeMapper
is in play, so maybe caching would still work in the case thatTypeMapper
isnull
.Similarly,
initializeFields()
callsgetFieldList()
which performs a boatload of reflection on fields that cannot change dynamically, and it does this for every instance construction. Using a cached field list would certainly cut down on the contention reported in #1616 while greatly speeding up the code.Again, is this a valid observation? If these are valid observations, I will happily submit a pull request addressing these two issues, awaiting feedback here.
The text was updated successfully, but these errors were encountered: