Internal: Performance issues

[Jay-o-Way]

Time/Location service

You might have seen that there can be a performance issue with the loading of the Time settings when using slow internet. This is because LoadGeolocationData can take quite some time. On slow wifi, it may take many (more than ten!) seconds to fill/update the "location" text box. At the moment, TimeViewModel contains LoadSettings and just a few lines later HandleConfigUpdate, and the last one also calls LoadSettings again. This all means that LoadGeolocationData() is called very often: every Page load and every change in the Radio buttons!

But when you think about it - a physical location is not expected to change ~much~ in this period, and the Geo Coordinates are "manual" input by definition. That's why I've already suggested to cache the data for quick UI load. And then move the bits that do the actual "retrieve", to app/window load event.

Saving and reading settings (broad scope)

• SaveConfig seems to be very inefficient. Calling File.Open with a FileMode.Create flag results in a new file being created every single time!
• Every _dispatcherQueue.TryEnqueue block, for the builder settings, looks extremely redundant to me. There must be a better way.

        _dispatcherQueue.TryEnqueue(() =>
        {
            _builder.Load();
            LoadSettings();
        });
  

• Have we thought about JSON?

investigate: Dialogs and Hyperlinks.

Prefer to use it the "normal" way.

check: changing UI language

async builder

Should

 _builder.Save();

be...?

 await _builder.SaveAsync(); // Ensure Save is awaited

[Spiritreader]

SaveConfig seems to be very inefficient. Calling File.Open with a FileMode.Create flag results in a new file being created every single time!

FileWatchers in Windows have a bug where sometimes changes to files are not picked up. This ensures that the file is always recreated and flushes properly, which allows the backend to detect this change and pull the configuration immediately.

[ChenYiLins]

I am working on this PR now. After some tests, SaveConfig is not as slow as expected. It will take less than 50ms for the first call, but it will hardly exceed 5ms afterwards. (My CPU is Intel i5-11260H)

But in fact, the slow network does make the UI update seriously lag behind, and caching data seems to be a good choice.

[Jay-o-Way]

SaveConfig is not as slow as expected

Maybe it's not slow, but is it good practice to create a new file every time?

[ChenYiLins]

Maybe it's not slow, but is it good practice to create a new file every time?

I'm not sure, but as Sam said, this is to avoid mistakes.