Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request - Toggling modules 1 by 1 #8

Open
Nedrapter opened this issue Aug 19, 2024 · 2 comments
Open

Feature request - Toggling modules 1 by 1 #8

Nedrapter opened this issue Aug 19, 2024 · 2 comments

Comments

@Nedrapter
Copy link

A mode where FTC would Deactivate one module at a time (and its dependencies if they are not used by another module).

The purpose of this is to monitor performance changes. I've noticed that I have an 80fps difference from modules on to no modules on. This number changes as modules get updated, removed or Foundry evolves. I would be very convenient to have this as an option to try and see which of your modules might have the biggest impact on your performance.

@esheyw
Copy link
Owner

esheyw commented Sep 23, 2024

Hi, sorry for missing this, I haven't been getting notifications properly for this repo.

Version 3.0 does set the precedent for modifications to the sorting algorithm, but this would be more like an entirely separate process. Still, I can see some use here; I'll consider for future versions.

@dineshm72
Copy link

I was coming to propose a slightly different request, but for the same or at least similar reasons.

Some issues are really caused (or at least exacerbated) by module load or computational load. Even if it's a single module that is responsible for the issue, it will be hard to observe under lesser loads. The divide and conquer method of the main FTC algorithm will often not be able to successfully replicate the issue at all, since it is reducing the module load by half each step. So you end up running through the entire tree and end up with an invalid culprit at the end. An approach which disables one module at a time (i.e. the proposal in this request) to try to identify one (or more) modules which are contributing to the issue while under nearly full module load is ideal for this case.

I think the only addition I would make is that you probably need to cycle through all the modules once (i.e. you shouldn't just stop once you find one module that seems to contribute), and have some way of specifying each as possibly contributing to the issue along the way. Then at the end you can try reloading with just that set of modules to confirm, or maybe just report out that it's these X modules that were tagged as contributing.

Yes, this would be time consuming, but it's what is needed to try to uncover these sorts of issues, and FTC is definitely making the process easier by automating the disabling and enabling of each module and keeping track of dependencies and whatnot along the way.

Perhaps you might optionally specify a grouping constant as part of the process, say 3 modules at a time, and disable them in groups to try to speed the process up slightly. Then at the end you can just specify all flagged mods and let the user continue on manually, or maybe you can try to dive more deeply into each group that was flagged by disabling just those groups one at a time to determine which of the three it was.

There is another type of issue, a multiple module conflict, which doesn't require a full load, but also won't usually work using the current method. I'll detail that one in a separate enhancement request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants