I am curious as to the performance benefits between using the
--display command in the command line, versus using Haxe reflection to retrieve type information, in order to populate autocompletion.
I suspect Haxe Reflection would be faster using the Haxe language, but as far as I know, it ignores meta-data such as “noCompletion” which
--display would otherwise take into consideration, unless a recent patch to Haxe reflection includes this.
I am also given to believe that IDEs such as FlashDevelop actually parses Haxe files manually, unless I’m missing something from the source code, there. I suspect this only because it freezes everytime you change the XML file, for a short period, and then at the bottom-right you see “Parsing x files…” so that’s just me assuming how an IDE such as FD does it. I’m curious as to why… performance?
What do you think?
lime display returns HXML compatible with Haxe in order to get type information, I believe that it then is fairly fast, especially depending on the caching/compilation server. Most IDEs keep the HXML returned from Lime cached until the project XML is changed
Reflection is used to get information at runtime, not when the application isn’t even build. Maybe you’re thinking of something else?
I understand how Reflection works. Intellisense in Visual Studio uses .NET Reflection to obtain type information at runtime and populate autocompletion, which is why I’m asking if there may be a performance benefit using Reflection in Haxe versus using the
--display command, should I decide to ever create my own code editor with auto-completion written in Haxe.
As far as I know visual studio use reflection on the dll dependencies not the project.
Compiling the project into a form or another to be able to use reflection on it at each autocomplete seems very slow.