Deeply nested widget trees with simple closure invocations have a high performance penalty

[dnfield]

Internal: b/292548521

Sample app:

import 'package:flutter/material.dart';

void main() {
  debugProfileBuildsEnabled = true;
  runApp(
    MaterialApp(
      routes: {
        '/two': (context) {
          return Material(child: Builder(builder: _getNestedBuilders(250)));
        }
      },
      home: Scaffold(
        body: Builder(builder: _getNestedBuilders(300)),
        floatingActionButton: Builder(
          builder: (context) {
            return FloatingActionButton(
              onPressed: () {
                Navigator.of(context).pushNamed('/two');
              },
            );
          },
        ),
      ),
    ),
  );
}

WidgetBuilder _getNestedBuilders(int count) {
  if (count == 0) {
    return (context) {
      return Container(
        width: 100,
        height: 100,
        color: Colors.red,
        child: IconButton(
          icon: const Icon(Icons.arrow_back_sharp),
          onPressed: () {
            Navigator.of(context).pop();
          },
        ),
      );
    };
  }
  return (context) => Builder(builder: _getNestedBuilders(count - 1));
}

A recorded timeline of this app on an Android Go device:
nested_builders.json.txt

This more-or-less mimics (and exaggerates) a common pattern in larger apps, where building the whole route can trigger a deeply nested widget heirarchy many of which are just Builder (or effectively Builder) widgets.

Initial build times on these routes on an Android Go device takes several milliseconds (compared to a fraction of a millisecond with much lower values in the _getNestedBuilders calls, or even compared to subsequent builds where they are not all marked as dirty).

I tried the following Dart program thinking it might replicate this issue, but it seems to just inline the calls:

import 'dart:developer';

class BuildContext {}

class Widget {}

typedef WidgetBuilder = Widget Function(BuildContext);

class Builder extends Widget {
  Builder({required this.builder});

  final WidgetBuilder builder;

  Widget _doBuild(BuildContext context) {
    try {
      return builder(context);
    } catch (e) {
      return Widget();
    }
  }

  Widget build(BuildContext context) {
    // Seems to defeat inlining, although I have not been able to replicate that
    // with simpler try catches.
    // return Timeline.timeSync('builder callback', () => builder(context));

    // Does not defeat inlining.
    // return _doBuild(context);

    // Seems to just inline and is fast.
    return builder(context);
  }
}

void main() {
  Timeline.timeSync('a', () {
    Builder(builder: (_) {
      print('hello, world!');
      return Widget();
    }).build(BuildContext());
  });

  Timeline.timeSync('b', () {
    Builder(builder: _getNestedBuilders(300)).build(BuildContext());
  });
}

WidgetBuilder _getNestedBuilders(int count) {
  if (count == 0) {
    return (_) {
      print('goodbye, world!');
      return Widget();
    };
  }
  return (_) => Builder(builder: _getNestedBuilders(count - 1)).build(_);
}

[goderbauer]

Does Builder vs. Container make a difference?

[dnfield]

Container is about as slow for the initial build.

[dnfield]

From offline discussion: don't think this is related to inlining at all. It just seems like it's expense from inflating/mounting elements, but still not entirely clear why. Adding tracing for this is hard because it gets noisy.

[dnfield]

It seems like each widget build gets a self time around 20us. 300 of them gets you to about 6ms of overhead. If any of these do more real work it gets worse.

[xster]

Could they just be the cost debugProfileBuildsEnabled? e.g. have you AB tested with and without debugProfileBuildsEnabled?

[dnfield]

Yes - also some tests where we eliminate runtimeType.toString from those traces.

It's likely that the actual work is a little less than 20us per widget, but when you have hundreds of them it adds up to ms of frame budget.

[jonahwilliams]

FWIW when I looked at this the profiles were dominated by the timeline. If you go through and remove all the timeline calls in framework.dart (not necessary for a CPU profile) you might find the performance to be significantly different - it was on a Pixel 4 at least, though I don't have access to an Android Go device to verify.