[Request] [Idea] Flutter Performance Lints

[ghost]

@henry2man commented on May 14, 2021, 6:07 AM UTC:

TL;DR:

As a developer -sometimes- I introduce performance problems in my applications 😅 What if the Flutter plugin helps me detect and fix them?

Full story:

Reviewing some articles on recommendations to improve the performance of applications made with Flutter, I find some elements that could be added to the plugin to help developers improve the performance of their apps.

For example:

• It is recommended not to use methods that create Widgets (or lists of Widgets) within the build() method. Instead, specific Widgets must be created (https://www.youtube.com/watch?v=vVg9It7cOfY&t=1320s, https://blog.codemagic.io/how-to-improve-the-performance-of-your -flutter-app./#dont-split-your-widgets-into-methods)
• It is recommended to use lazy lists instead of creating all items manually (https://flutter.dev/docs/perf/rendering/best-practices#render-grids-and-lists-lazily)
• It is recommended not to use the Opacity widget (https://flutter.dev/docs/perf/rendering/best-practices#pitfalls)

I am not an absolute specialist in performance with Flutter but I have debugged on other platforms and it is a very important element in mobile apps.

My suggestion is that some of these items could appear as part of the warnings and/or as part of a specific performance analysis extension within the plugin.

What do you think?

This issue was moved by pq from flutter/flutter-intellij#5484.

@stevemessick commented on May 17, 2021, 1:58 PM UTC:

@pq These sound like possible lint additions. What do you think?

@pq commented on May 18, 2021, 11:54 PM UTC:

Excellent ideas @henry2man! I'll transfer this issue over to the linter, which is where such analysis would happen. Thanks!

[pq]

/fyi @jacob314 @goderbauer

[henry2man]

@pq commented on May 18, 2021, 11:54 PM UTC:

Excellent ideas @henry2man! I'll transfer this issue over to the linter, which is where such analysis would happen. Thanks!

@pq I'm glad to hear it. And yes, it is true that an approach through the linter would allow these tips to be shown in any environment.

I'm not quite sure how I could contribute, especially given how complex this issue can be, but count on me if you need code samples that can be improved 😅.

[pq]

@henry2man: sample code would be most welcome!

[goderbauer]

Just to add some color: The examples quoted in the top comment are not hard rules and it depends on the particular circumstances whether the listed things should be avoided. There's a place for the Opacity widget if you really need a transparent effect and non-lazy ListViews can be fine for small lists. Similarly, methods that return other widgets are not always evil.

[jacob314]

Fyi @davidmorgan this is a good example of lint that would probably only make sense to show as a hint while you are authoring code rather than an always active lint.
For some of these we might also be able to show them if we have other evidence from running a profile build of an application that the associated widgets are responsible for a large amount of the apps runtime.

[henry2man]

Just to add some color: The examples quoted in the top comment are not hard rules and it depends on the particular circumstances whether the listed things should be avoided. There's a place for the Opacity widget if you really need a transparent effect and non-lazy ListViews can be fine for small lists. Similarly, methods that return other widgets are not always evil.

I agree with that. For this reason, in my initial proposal (oriented to the Intellij plugin) I also talked about the option of showing a specific report on potential performance problems.

Would it be possible to consider some parameter in the pubspec.yml file that would make the linter more "verbose" and thus show the results of this kind of analysis? I'm thinking in something disabled by default (or not, it could be useful in new projects) but well documented with comments in the pubspec.yml default file template.

[bwilkerson]

... this is a good example of lint that would probably only make sense to show as a hint while you are authoring code rather than an always active lint.

I assume you said that because of a perceived high probability of false positives and are concerned that such lints should not prevent code from being committed (both of which I agree with). If that's wrong, could you please explain the motivation for this comment (and largely ignore the following).

There has been at least one study done to measure the impact of false positives on user trust. The results showed that, not only does a lint with false positives degrade user trust in that lint, but it actually degrades user trust in all the other lints. As a result, we have always held our lints to a very high standard in this respect. While we don't strictly require that there be no false positives, we do require that false positives are very rare and we do our best to fix false positives when they're discovered, sometimes even at the cost of false negatives. I don't believe that we want to change that policy.

As a result, I don't believe that we want to add any performance related lints unless we can identify the conditions under which a performance problem is virtually guaranteed. I don't know enough about these specific APIs to know for sure, but phrases like "really need", "can be fine", and "not always" sound to me like conditions that are not discoverable through static analysis.

... in my initial proposal (oriented to the Intellij plugin) I also talked about the option of showing a specific report on potential performance problems.

That sounds like a much better way to surface this kind of analysis. I believe that there is value in having tooling to help users optimize performance, and I believe there's value in having analysis tools like this that can be run at discrete moments. I believe that such tools can report possible issues without compromising user trust by being very transparent in the way the issues are reported.

In my opinion such a tool would be better if it could also present some level of confidence in a result. For example, if we could identify multiple characteristics that cause performance issues when using an API then we could base the confidence level on the number of characteristics that are present in the code being analyzed.

But another interesting avenue for consideration might be a tool that could actually measure the performance impact of an API's use in context. I can think of a couple of possibilities. Perhaps it could automatically instrument the code, capture a performance profile, and analyze the data to report the impact of suspect APIs. Or perhaps it make changes to the code (such as removing an Opacity widget from the hierarchy), run the app, and measure the performance difference.

[henry2man]

If we think of a tool that does code analysis (either static or dynamic as in the example explained by @bwilkerson) I think the ideal would be to decompose it into several sub-projects / components:

• A project with the analysis engine itself
• A command line utility (ex: "flutter performance" or something like that) that will consume the engine
• Extensions for the most popular editors (Android Studio, VSCode ...)