nanobind
leaks memory in builtin mesh generation?
#2884
Labels
question
Further information is requested
nanobind
leaks memory in builtin mesh generation?
#2884
I have been struggling for the last couple of days in my
multiphenicsx
CI, where I have parallel unit tests that (on the same commit ofmultiphenicsx
, and samedolfinx/dolfinx:nightly
image) take either 10 minutes (as expected) or 3 hours.I've simplified my CI and ran, out of all my tests, only this test
https://github.com/multiphenics/multiphenicsx/blob/artifact/tests/unit/fem/test_dofmap_restriction.py
which is heavily parametrized, for a total of more than 50 possible configurations.
I then ran only that test, either in serial or in parallel on three processors. I profiled a good CI run (which takes 3.670 s in parallel) and a bad CI run (which takes 122.788 seconds in parallel).
I attach the profiling results in pstats.zip: you have two cases (good vs bad),
cProfile
files for a serial vs parallel run, and in each case an auxiliary fileprint.py
to print the following tables on process #0 of the parallel run.For the good case (https://github.com/multiphenics/multiphenicsx/actions/runs/6810825566/job/18519911648), I get:
For the bad case (https://github.com/multiphenics/multiphenicsx/actions/runs/6810780257/job/18519767431), I get
In this second table, notice in particular
where https://github.com/multiphenics/multiphenicsx/blob/artifact/tests/unit/fem/test_dofmap_restriction.py#L20 is a fixture that generates a builtin mesh.
Could there be a memory leak (or something similar) in
nanobind
wrappers of builtin mesh generators that causes this?The text was updated successfully, but these errors were encountered: