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?
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
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.
