Since I work a lot on performance issues, I tend to agree with your comments @Stephen Canzano .  

For me, the truth is the query plan and the number of GloRef \commands executed at runtime.

@Irene Mykhailova I wonder how the result would with a clear cache between each query.

We can clear the cache with : 

d ClearBuffers^|"%SYS"|GLOBUFF()

don't do this in production ;-)

In my own experience, the efficiency of the IRIS cache can hide problems or be misleading.

In recent versions, I think the difference could be marked for embedded SQL on the first run only if “sqlcompile mode=deferred” is not used.  deferred mode is the default mode for years and can be overridden with a compile qualifier (and maybe a system-wide parameter).

Yes, that's it!

The methods generated in the “impl” class must return a %DynamicObject.  I think %WriteResponse accepts string, stream or %DynamicObject as parameters, but the most common usage is still %DynamicObject (The developer will always be free to modify according to his implementation) .  I'll put an issue on github for follow-up and fix it.  

edit: done in version 1.1.1

Great!
Probably an oversight in the return type when generating the code.  
I'll take a look.