Hi Harbs - just in reply to your specific questions:
As I mentioned elsewhere it is easy to have full speed index access and
also full speed pop() and unshift() methods
If you switch off the first 3 settings I outlined in the post titled
'Language/Reflection improvements details' you will have that. Those
settings are switchable locally with doc directives as well. I will do a
full write-up this coming weekend for docs. Hopefully I can harvest a lot
of what I already wrote elsewhere for that.
BTW I switched TLF to use the legacy Vector-as-Array approach by default, I
am not sure what you want there, you could undo that if you prefer.
Beyond the above mentioned approaches for (mainly index level)
optimization, I have a preference for two more approaches, but I'd rather
limit the overall number of options to be what people definitely need
instead of adding too many options (which could create confusion). I think
your other proposal with Josh for the typed Arrays and their greater
compile-time safety will be a better fit for many cases as well, so I hope
that happens. If I have time to help out in any way with that, I would be
happy to do so as well, because it sounds like something I would use a lot.
Anyhow, I do want to support more optimizations with this implementation.
Can you say what your main concerns would be for optimization? Is it mainly
for 'push' (and unshift) ? Those would be mine...
I would personally like to see the following:
1. A global optimization setting that affects all instances in all code
including pre-built library code. This would avoid certain runtime checks
and would also result in a lighter implementation. This is something the
final application developer decides, not anything dictated by a library
developer (but a library developer could advertise their public swc as
being compatible/safe with this type of optimization). This approach could
include perhaps 2 levels: one to remove any code paths related to fixed
length Vectors (which I think you said you never used) for example. Then
another possibly removing all element level type-checking as another level.
Adding this should not be too difficult I think and would be determined via
a goog define (which might be driven by a compiler setting, I did not look
at how easy this is yet). The thing I like about this approach is that it
is not 'baked-in' to any instance and the application developer makes the
ultimate decision and owns the associated risk (as opposed to having it
imposed on them by a library developer, for example). I think the removal
of support for 'fixed' Vectors could probably be made to generate
(debug-only) errors if there is code that runs that sets fixed to true on
any Vector instance - to provide some reassurance of no side effects when
choosing this option.
2. Compilation scoped optimizations.
By 'compilation-scoped' I mean configurable in the same way as the
vector-index-check suppression: An over-arching config setting for the
current compilation that can be overridden locally with doc comment
directives. This affects code sites (or all current compilation scope if
set in the config) and not specific instances. I would hope this might be
the only other 'Vector' specific config option like this, simply to avoid
confusion with too many options.
So I personally think the important things here are the push and unshift
methods, because they're the ones that are also most often used in loops
when index level access or assignment is not being used (in the loop). But
I'm keen to hear more about what people want in case it's different to how
I think. And I will add support for what best represents the needs of the
community. While index level access is best for large loops (just as it is
for 'Array'), push could be preferred in small loops because it does not
require a 'get' for length to establish the upper bound of the loop or the
next acceptable index to set (for non-fixed Vectors). The optimization for
push in this case would be to bypass runtime typechecking and just do a
regular Array.push into the underlying Vector representation, which is
still actually an Array in terms of how javascript sees it. Adding this
option is easy also, but rather than just forging ahead with it, I am keen
to get input from others first.
I consider that specific instance level optimizations (in general) are
'dangerous' because even if the code is 'safe' when it is originally
written, subsequent changes to the overall codebase (possibly by different
developers) can mean that an instance ends up elsewhere in code where it
behaves differently from other instances of the same type. Code-site
optimizations could also create an unusual internal state for an instance,
but most often they should not, because the code site where the
optimization is used should be validated in terms of the optimization by
its original developer (e.g. no runtime type checking at a particular usage
site because it is never needed in the context of that code, for example)
and the behavior of the same instance elsewhere should be much less of a
risk.
More feedback from you or anyone else is definitely welcome for what they
want to see for optimization options of the implementation. I'm sure I can
still find more ways to improve the implementation for speed as it is now
as well, I can think of a one thing I want to investigate further.
-Greg
On Wed, Jun 12, 2019 at 1:54 AM Harbs <harbs.li...@gmail.com> wrote:
> Practical question for me is: How do we disable to Vector runtime
> checking? I was having trouble following the full discussion. My
> understanding was that there’s a compiler flag, but I’m not sure what it is.
>
> > On Jun 11, 2019, at 7:10 AM, Yishay Weiss <yishayj...@hotmail.com>
> wrote:
> >
> > Language.js:868 [1] is
> >
> > if (elementType.indexOf('Vector.<') == 0) {
> >
> >
> >
> > ________________________________
> > From: Yishay Weiss <yishayj...@hotmail.com>
> > Sent: Tuesday, June 11, 2019 2:07:36 PM
> > To: dev@royale.apache.org
> > Subject: Problem with Vectors
> >
> > Hi Greg,
> >
> > I just updated Royale and I’m seeing that in our class FontLoader
> >
> > private var _fonts:Vector.<Font> = new Vector.<Font>();
> >
> > gets transpiled to
> >
> > this.com_printui_text_engine_FontLoader__fonts =
> org.apache.royale.utils.Language.Vector();
> >
> > Notice how the type isn’t given in Vector’s constructor. This results in
> a runtime error [1]. Any ideas?
> >
> > [1]
> >
> > TypeError: Cannot read property 'indexOf' of null
> > Watch
> > Call Stack
> > org.apache.royale.utils.Language.VectorSupport.vectorElementCoercion
> > Language.js:868
> > org.apache.royale.utils.Language.synthVector
> > Language.js:642
> > org.apache.royale.utils.Language.Vector
> > Language.js:685
> > com.printui.text.engine.FontLoader
> > FontLoader.js:24
> >
>
>
