-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some general Vector3 optimizations #294
Conversation
@johnmccutchan fixed up |
I think we will want to seal this class to prevent it being extended. This will make performance and behaviour more reliable. The classes in vector_math were never designed to be extended. There are no guarantees which methods are implemented in terms of other methods to provide an extension point. When Dart 3 now has class modifiers to prevent classes being extended or implemented. When vector_math is revised to be a Dart 3 library, the ability to extend The efficiency concern is that extending a class makes calls to the base class methods be polymorphic. When the class is not extended, calls to a method can be resolved exactly and inlined or implemented as direct calls. When the methods have overrides, the calls are necessarily indirect calls as there may be more than one version of the method. For a simple class like
I worry that these changes may confuse the (somewhat brittle) analysis that allow the length of
These all seem like nice changes. |
Since that will be a big breaking change, I'm guessing you won't do that any time soon when looking at how this package has been developed previously? And therefore this change shouldn't make any difference meanwhile?
There is no documentation about that it shouldn't be extended either, and since it also hasn't been marked with the
There really should be some form of benchmark suite in this repository if it is that focused on performance, because these kind of claims are very hard to check otherwise.
Thanks! |
While I agree with the spirit of your suggestion @rakudrama I feel like this is likely to break a number of users of this library? How should we proceed? |
Actually, let's have that discussion in a separate issue: #298 |
@rakudrama what changes in this PR do you consider blocking? I'd like to split them off and land the non-controversial ones. |
I'm ok with everything except changes to the constructors (and anything that changes a public interface but as far as I remember, we fixed those). I am looking at the benchmark that was written to support changing the constructors. I understand that this CL is just following what was done and approved for Vector2. |
Since the
Vector3.zero
constructor was already a normal named constructor it was already possible to extend the class.Converts all factory constructors (exceptVector3.random
) to named constructors that directly sets the storage instead of calling intermediary methods to do it.length2
,dot
,isInfinite
andisNaN
.reflect
,relativeError
andabsoluteError
so that they don't create extraVector3
objects._v3storage
from 1 to 0 so that it is consistent across the class and guarantees that bounds checking is only done once.