Removing an out of date section (#12492)

Fixes #12472

Author: sfshaza2

src/content/add-to-app/performance.md

@@ -132,80 +132,6 @@ At this point, the [`Layer`][] tree generated by your Flutter
 program, per frame, is converted into
 OpenGL (or Vulkan or Metal) GPU instructions.
 
-## Memory and latency
-
-Showing a Flutter UI has a non-trivial latency cost.
-This cost can be lessened by starting the Flutter engine
-ahead of time.
-
-The most relevant choice for add-to-app scenarios is for you
-to decide when to pre-load a `FlutterEngine`
-(that is, to load the Flutter library, start the Dart VM,
-and run entrypoint in an isolate), and what the memory and latency
-cost is of that pre-warm. You also need to know how the pre-warm
-affects the memory and latency cost of rendering a first Flutter
-frame when the UI component is subsequently attached
-to that `FlutterEngine`.
-
-As of Flutter v1.10.3, and testing on a low-end 2015 class device
-in release-AOT mode, pre-warming the `FlutterEngine` costs:
-
-* 42 MB and 1530 ms to prewarm on **Android**.
-  330 ms of it is a blocking call on the main thread.
-* 22 MB and 860 ms to prewarm on **iOS**.
-  260 ms of it is a blocking call on the main thread.
-
-A Flutter UI can be attached during the pre-warm.
-The remaining time is joined to the time-to-first-frame latency.
-
-Memory-wise, a cost sample (variable,
-depending on the use case) could be:
-
-* ~4 MB OS's memory usage for creating pthreads.
-* ~10 MB GPU driver memory.
-* ~1 MB for Dart runtime-managed memory.
-* ~5 MB for Dart-loaded font maps.
-
-Latency-wise,
-a cost sample (variable, depending on the use case) could be:
-
-* ~20 ms to collect the Flutter assets from the application package.
-* ~15 ms to dlopen the Flutter engine library.
-* ~200 ms to create the Dart VM and load the AOT snapshot.
-* ~200 ms to load Flutter-dependent fonts and assets.
-* ~400 ms to run the entrypoint, create the first widget tree,
-  and  compile the needed GPU shader programs.
-
-The `FlutterEngine` should be pre-warmed late enough to delay the
-memory consumption needed but early enough to avoid combining the
-Flutter engine start-up time with the first frame latency of
-showing Flutter.
-
-The exact timing depends on the app's structure and heuristics.
-An example would be to load the Flutter engine in the screen
-before the screen is drawn by Flutter.
-
-Given an engine pre-warm, the first frame cost on UI attach is:
-
-* 320 ms on **Android** and an additional 12 MB
-  (highly dependent on the screen's physical pixel size).
-* 200 ms on **iOS** and an additional 16 MB
-  (highly dependent on the screen's physical pixel size).
-
-Memory-wise, the cost is primarily the graphical memory buffer used for
-rendering and is dependent on the screen size.
-
-Latency-wise, the cost is primarily waiting for the OS callback to provide
-Flutter with a rendering surface and compiling the remaining shader programs
-that are not pre-emptively predictable. This is a one-time cost.
-
-When the Flutter UI component is released, the UI-related memory is freed.
-This doesn't affect the Flutter state, which lives in the `FlutterEngine`
-(unless the `FlutterEngine` is also released).
-
-For performance details on creating more than one `FlutterEngine`,
-see [multiple Flutters][].
-
 [android-engine]: {{site.api}}/javadoc/io/flutter/embedding/engine/FlutterEngine.html
 [auxiliary threads]: {{site.repo.flutter}}/blob/main/docs/about/The-Engine-architecture.md#threading
 [CAEAGLLayer]: {{site.apple-dev}}/documentation/quartzcore/caeagllayer