Sadly, you obviously haven't yet understood how tracing or JIT works.
What you are referring to is not tracing, but a specific technique which involves
tracing. All I needed to hear was:
this blogger[/url]":16b3gf90]'Tamarin Tracing' is an implementation that uses a 'tracing jit'. This type of 'just in time compiler' traces code executing during hotspots and compiles it so when those hotspots are entered again the compiled code is run instead.
To paraphrase, it is a technique used to avoid compiling code that is not
executed frequently. Now I see how this could
be applied to AutoHotkey: Use the existing DllCall methods, and compile only for frequently-used calls. I am not convinced it would provide enough benefit over simply compiling every unique call.
Either way you need processing to find the relevant compiled function for each call, or to determine whether there is one. (That is not to say I won't try it, only that I expect #DllFunction to have better results.)
Think about it; DllCall() has scope for improvement but you throw in #define and #DllFunction to the mix,
implement #DllFunction with different syntax. What is the difference from the user's perspective?
I was drawing a comparison between #DllFunction and your suggestion about #define, not between #define/#DllFunction and optimising DllCall().
It's very common in the FOSS world to see many forks dying because developers believed their radical ideas would take off,
There need only be one user of AutoHotkey_L for development to continue.
I jumped in late in the discussion and all I saw was you advocating new syntax.
It would be wise to read the discussion before jumping into it.