google / reflectable.dart

Reflectable is a Dart library that allows programmers to eliminate certain usages of dynamic reflection by specialization of reflective code to an equivalent implementation using only static techniques. The use of dynamic reflection is constrained in order to ensure that the specialized code can be generated and will have a reasonable size.

Home Page:https://pub.dev/packages/reflectable

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Question] - Stats on Bundle Sizes and Performance Implications/metrics of using Reflectable ?

dinbtechit opened this issue · comments

Hi, it's me again. lol

I'm wondering if you have the following stats on Bundle Sizes and Performance metrics for Reflectable vs Plain Dart vs Source Gen

Metrics Type Reflectable Plain Dart/Flutter Source Gen Best Practices/Trade offs
Bundle Size
Startup time
Memory Usage
CPU Usage

This is a great talk that provides some metrics for bundle size but it's 7 years old. Looking for some additional metrics and any improvements that might have gotten included in the recent releases.

This is a great talk

Thanks for the kind words!

but ... Looking for some additional metrics

I don't have benchmarks of that nature. Also, reflectable is a code generation based approach, and code generation would include a large number of different approaches, with radically different benchmarking results. It is probably not even possible to say anything which is actually useful as an estimate of those space and time related properties for any concrete case.

It is a bit like the average length of a document: You might find a way to measure the length of a large number of documents, and you might come up a rather precise estimate for the average length, but it isn't going to say anything useful about the expected length of any particular document.

It is probably more useful to use qualitative characterizations: General (built-in) reflection tends to cause programs to grow radically in size, because it is very unlikely that any static analysis can prove that any code is dead. That's the reason why built-in reflection is restricted very firmly in the Dart world.

Reflectable is based on a different approach: The developer makes precise decisions about which declarations to cover, and how, and the run-time support for reflection will then cover exactly those declarations. If the running program makes an attempt to get a mirror for an instance of a class that doesn't have reflection support of the requested kind then it is a run-time error (NoSuchCapabilityException). The fact that the whole thing is based on code generation ensures that it is known at compile-time how much code the reflection support gave rise to. On the other hand, everything in the program which is given reflection support will be prevented from being tree-shaken away, because the generated code contains references to it.

Code generation in a broader sense can of course be tailored exactly to the given purpose, which makes it equivalent to optimal hand-written code, plus some amount of waste which is caused by the code generation algorithm being less than optimal (and less than optimally configured).

I think the only realistic way to make a choice will be to ask around and hear about the experiences of other people (for instance, in this thread), and to perform experiments.