[Toolkit bug]: Material Ingestion has significant overhead that scales poorly with number of files.

[onnoj]

Contact Details (Optional)

No response

Describe the bug

The bug There seems to be a performance bug in the toolkit's Material Ingestion UI. There are two instances where this occurs:

• When adding a large number of files to the material ingestion screen's "Input File Paths" section.
• When the queue is being processed/ingested after pressing the "Add to Queue" button.

In both cases, the program becomes unresponsive. In the 2nd case, the program hangs for a long time between converting each texture (the actual conversion takes very little time).

So, the more files I add, the slower everything becomes (in a non-linear fashion).

Diag A rudimentary capture using Very Sleepy (a free sampling profiler) shows one thread busy with everything else (mostly) idle, with the majority of the calls stemming from: omni::ui::* going into python. If I were to guess, it seems that for every item added to the list, the entire list is refreshed and processed.

As a test, I've added +/- 9900 png files to the ingestion list, each are 2x2. In total, this is about 1,20 MB of data. While adding these to the file list, checking kit.exe's file activity with Microsoft SysInternals Procmon, I see that all files are repeatedly accessed. In a time span of +/- 30s, all files are accessed up about 16 times: The operation in question is QueryOpen, to get the file attributes.

There is a partial workaround; the user can drag & drop all files into the "Input File Paths" list, after which they are added almost instantly. However, the performance issue comes back once the items are being processed. In this case, Procmon shows the file being processed, followed by many many many QueryOpen's to all files, before processing another single file.

CPU shows 100% on a single core, there is no noteworthy gain in CPU mem or GPU mem, GPU usage is effectively idle.

How do you reproduce the bug?

1. Grab and extract the test files: ingestionbug.zip
2. Go to RTX Remix toolkit, browse to the "Ingestion Tab", and then to "Material(s)"
3. Add the text files to the list via "Add" (or, drag & drop and skip to step 5)
4. Observe extremely long waiting time
5. Click add-to-queue
6. Observe slow ingestion rate, combined with long periods of unresponsiveness.

Logs from overnight run: kit_20240404_012712.log

What is the expected behavior?

The expected behavior:

• When adding a large number of files to the "Input File Paths" section, the UI should remain responsive and allow for smooth addition of files regardless of the quantity. Ideally, it should not be blocked by file operations.
• According to procmon, the toolkit aggressively fetches and re-fetches the file attributes of the to be processed files. I don't know how much this actually impacts performance itself, but, perhaps it should be less aggressive. For example, the results can be cached within the application, or, perhaps the number of files refreshed can be limited to only what's in the view of the editor.
• Ideally, the ingestion process should run independently, and not be blocked by UI.

Version

2024.2.1

[nvdamien]

Hi @onnoj ,

For the next release, the ingestion will use an external process that will not affect the current process (the app). Also, the doc will be updated with a simpler CLI.

All of that should already unlock a lot of things.

For the UI that is slow when dropping a long list of textures, we will investigate: REMIX-2949