On Sat, May 18, 2019 at 2:57 PM Ryan Joseph <[email protected]> wrote:
> I wanted to make an alternate capture mode as an optimization for closures > that don’t get passed outside of their scope but I wasn’t able to figure > this out yet (using old-style objects instead of classes). It’s a waste to > allocate a new class if not needed (this would hurt realtime graphics > applications badly) so that should be tackled eventually. Maybe they can be > made to inline or something, not sure how to handle it though. > Even if it doesn't happen right away, I 100% agree that this needs to be how they work eventually (which will not break Delphi compatibility, because how they work internally is irrelevant as long as the external means to access / use anonymous functions is roughly the same.) Currently I actually tend to avoid anonymous functions in Delphi for "small" callback-esque use cases where no capturing happens, because they *are* in fact objectively slower than function pointers due to how they allocate and destroy a class instance on every call (for no good reason.) That is *not* how they work in most languages, for anyone skeptical, BTW. Every existing not-Delphi "native" compiler, for a multitude of different languages, that implements anonymous functions in some way not only *does not* allocate anything on the heap in non-capturing cases, but in fact fully inlines them thus completely eliminating the function call overhead as well. That ties in to how I'd also love to see FPC be able to inline normal "procvars" like most compilers do, but I suppose that's a different story...
_______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
