I have created a barebone reproduction of an issue we first observed wrt. Realm.
You can find it on github here: https://github.com/nielsenko/weird
It basically allocates and leave as garbage a lot of PointHandles that holds a Pointer<Point> where Point is a struct bound via ffi.
In the ctor of PointHandle I allocate a Point struct and attach the pointer to a NativeFinalizer to ensure the native memory is freed when the handle is GC'ed. On attach I set externalSize : 16 which is important (I dont see the issue if II forget to set externalSize)
When I allocate (and leave as garbage) a lot of PointHandles in a loop, I see a drop in the speed of allocations after a while.
I would expect the GC to kick in, clean out some handles, causing speed to degrade while it happens, but I would also expect the speed to recover after the GC has run. The latter does not seem to happen, at least not to the pre-first-gc speed.
Example output:
8585000 all: 0:00:10.510152, lap: 0ms, live points: 305499
8586000 all: 0:00:10.510682, lap: 0ms, live points: 306499
8587000 all: 0:00:10.511202, lap: 0ms, live points: 307499
8588000 all: 0:00:10.511721, lap: 0ms, live points: 308499
8589000 all: 0:00:10.533678, lap: 21ms, live points: 309499
8590000 all: 0:00:10.534269, lap: 0ms, live points: 310499
8591000 all: 0:00:10.534927, lap: 0ms, live points: 311499
8592000 all: 0:00:10.535493, lap: 0ms, live points: 312499
8593000 all: 0:00:10.536042, lap: 0ms, live points: 313499
8594000 all: 0:00:10.536587, lap: 0ms, live points: 314499
8595000 all: 0:00:10.537132, lap: 0ms, live points: 315499
8596000 all: 0:00:10.537685, lap: 0ms, live points: 316499
8597000 all: 0:00:10.538228, lap: 0ms, live points: 317499
8598000 all: 0:00:10.538781, lap: 0ms, live points: 318499
8599000 all: 0:00:10.539314, lap: 0ms, live points: 319499
8600000 all: 0:00:11.967296, lap: 1427ms, live points: 320499 // <--- I find this jump weird
8601000 all: 0:00:14.060393, lap: 2093ms, live points: 321499
8602000 all: 0:00:16.150930, lap: 2090ms, live points: 322499
8603000 all: 0:00:18.215032, lap: 2064ms, live points: 323499
8604000 all: 0:00:20.282250, lap: 2067ms, live points: 324499
8605000 all: 0:00:22.361571, lap: 2079ms, live points: 325499
8606000 all: 0:00:24.432646, lap: 2071ms, live points: 326499
First row is number of objects (PointHandle + Point) allocated, then total time, time since previous line, and last the current number of live Point structs - these are counted on the native side.
Environment:
Dart SDK version: 2.18.4 (stable) (Tue Nov 1 15:15:07 2022 +0000) on "macos_arm64"
Flutter 3.3.8 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 52b3dc25f6 (2 weeks ago) • 2022-11-09 12:09:26 +0800
Engine • revision 857bd6b74c
Tools • Dart 2.18.4 • DevTools 2.15.0
I have created a barebone reproduction of an issue we first observed wrt. Realm.
You can find it on github here: https://github.com/nielsenko/weird
It basically allocates and leave as garbage a lot of
PointHandlesthat holds aPointer<Point>wherePointis a struct bound via ffi.In the ctor of
PointHandleI allocate aPointstruct and attach the pointer to aNativeFinalizerto ensure the native memory is freed when the handle is GC'ed. On attach I setexternalSize : 16which is important (I dont see the issue if II forget to setexternalSize)When I allocate (and leave as garbage) a lot of
PointHandles in a loop, I see a drop in the speed of allocations after a while.I would expect the GC to kick in, clean out some handles, causing speed to degrade while it happens, but I would also expect the speed to recover after the GC has run. The latter does not seem to happen, at least not to the pre-first-gc speed.
Example output:
First row is number of objects (
PointHandle+Point) allocated, then total time, time since previous line, and last the current number of livePointstructs - these are counted on the native side.Environment:
Dart SDK version: 2.18.4 (stable) (Tue Nov 1 15:15:07 2022 +0000) on "macos_arm64"
Flutter 3.3.8 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 52b3dc25f6 (2 weeks ago) • 2022-11-09 12:09:26 +0800
Engine • revision 857bd6b74c
Tools • Dart 2.18.4 • DevTools 2.15.0