Bug: Memory Leak in Details View

[SemyonL]

Description

There is a memory leak when using Details View. Here is the list of snapshots I've got using profiler on preview version of the app.

#	Type	Count	Size (B)	Inclusive size (B)
1	Files.App.Views.Layouts.DetailsLayoutPage	1	1008	230648
2	Files.App.Views.Layouts.DetailsLayoutPage	11	11088	974472
3	Files.App.Views.Layouts.DetailsLayoutPage	11	11088	941184
4	Files.App.Views.Layouts.DetailsLayoutPage	22	22176	1785048
5	Files.App.Views.Layouts.DetailsLayoutPage	22	22176	1750928
6	Files.App.Views.Layouts.DetailsLayoutPage	33	33264	2897424
7	Files.App.Views.Layouts.DetailsLayoutPage	33	33264	2559384
8	Files.App.Views.Layouts.DetailsLayoutPage	44	44352	3555584
9	Files.App.Views.Layouts.DetailsLayoutPage	44	44352	3555944
10	Files.App.Views.Layouts.DetailsLayoutPage	55	55440	4209608
11	Files.App.Views.Layouts.DetailsLayoutPage	55	55440	4213368

First snapshot after the app is started and 1 tab is open. On even snapshots more tabs with details view are created, on odd snapshots tabs are closed, but as you may see from the table the memory is not freed. On the last snapshot I've closed the window, but the app was running in background, and memory is not freed.

Steps To Reproduce

1. Open Files
2. Open any folder in details view
3. Duplicate the tab several (5-10) times
4. Close tabs
5. Repeat 2-4

Files Version

3.9.15.0

Windows Version

10.0.26120.5751

User ID

d46219e3-896b-483f-b7af-f95fd0051fa6

Log File

debug.log

[yaira2]

Thank you for the report. This is unfortunately an ongoing issue since the beginning of Files, navigating to different directories, closing tabs etc doesn't free up memory. See #4180.

@hez2010 is currently working on a new garbage collector that might help, but in any event, if you learn anything more or have a fix, please let us know.

[0x5bfa]

Btw our new plans on this is to avoid using Page class but to use ContentPresenter, setting UserControls instead. This way enable us to pass data to the folder browser and the inner folder views (which are UserControls) via Dependency Properties.

The primary structure would be:

• MainContent
  • TabView
  • NavigationToolbar
  • SidebarView
    • SidebarView.Content
      • Toolbar
      • ContentPresenter (the main view)
      • DetailsPane
      • StatusBar
      • etc.

Possibly connects to:

• FolderBrowser [UserControl]

  • DetailsFolderView [UserControl] (Collapsed)
  • GridFolderView [UserControl] (Collapsed)
  • ListFolderView [UserControl] (Visible)
  • TilesFolderView [UserControl] (Collapsed)
  • etc.

• SettingsView

• ReleaseNotesView

• etc.

---

Plus, it looks like we also have disposal issues on native objects + C# managed event hooks. As for the native objects, we're trying to introduce a new kind of the container that represents either a file or a folder (or both) which can be disposed of easily.
For more info, see src/Files.App.Storage/Windows/ folder. The old code is in src/Files.App/Utils/Storage

[SemyonL]

our new plans on this is to avoid using Page class

Since these views represent the same data and the user doesn’t actually navigate between them, using Page brings in navigation-related logic that isn’t needed. A simpler container should be a better fit.

Regarding visibility management: while using Collapsed works, it may be worth considering x:Load instead. Unlike Collapsed, which only skips layout/arranging but still keeps controls alive with active bindings, x:Load can prevent the creation of hidden controls entirely. This helps free memory and can improve performance too.

[0x5bfa]

Regarding visibility management: while using Collapsed works, it may be worth considering x:Load instead. Unlike Collapsed, which only skips layout/arranging but still keeps controls alive with active bindings, x:Load can prevent the creation of hidden controls entirely. This helps free memory and can improve performance too.

We probably won't use Visibility for this scenario: we will use SwitchPresenter from Windows Community Toolkit 8.x, which holds the all instances assigned to each Case but only shows the content of the current Case to load its XAML. If you switch the layout, the XAML of the previous Case will be discarded and the one of the new Case will be loaded, which is essentially the same as x:Load.

<!-- In FolderBrowser.xaml -->
<toolkit:SwitchPresenter TargetType="data:LayoutType" Value="{x:Bind LayoutType, Mode=OneWay}">
    <toolkit:Case Value="Tree">
        <controls:TreeFolderView .../>
   </toolkit:Case>
    <toolkit:Case Value="Grid" .../>
    <toolkit:Case Value="Columns" .../>
    <toolkit:Case Value="List" .../>
    <toolkit:Case Value="Details" .../>
</toolkit:SwitchPresenter>

However, since we're also pretty sure that loading a layout must be performant, I may change my mind. Like, another solution is to create a Grid where these folder view UserControls are set (overlapping these controls) and add folder view controls as loaded (i.e., when changing the current layout to another), managing the visibility of them via the Visibility prop so the bindings are kept and users can quickly change the layouts to previously loaded layouts.