[GH-ISSUE #445] Bad startup performance depending on network availability #2284

Closed
opened 2026-03-01 17:19:24 +03:00 by kerem · 8 comments
Owner

Originally created by @majkinetor on GitHub (Jul 4, 2023).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/445

Originally assigned to: @VShawn on GitHub.

The first one is just bad (~5s)

details

Animation1

The second one is extremelly bad, it takes 20 seconds. I disconnected from the VPN but later noticed that Internet wasn't working. It takes 20+s to show up:

details

Animation2

I noticed btw that there is no timer any more when VPN is disconnected, only Reconnecting constantly shown.

Any connection problem shouldn't influence main window - local database should always work. Even without local database (which is currently not possible), we should see remote database names ASAP.

Logs shows that it tries to connect to Github among other things, probably to check latest version?

details

1Remote.log_20230704.md

Originally created by @majkinetor on GitHub (Jul 4, 2023). Original GitHub issue: https://github.com/1Remote/1Remote/issues/445 Originally assigned to: @VShawn on GitHub. The first one is just bad (~5s) <details><summary>details</summary> ![Animation1](https://github.com/1Remote/1Remote/assets/85767/afc74d03-cd41-4408-befa-1149432b3216) </details> The second one is extremelly bad, it takes 20 seconds. I disconnected from the VPN but later noticed that Internet wasn't working. It takes 20+s to show up: <details><summary>details</summary> ![Animation2](https://github.com/1Remote/1Remote/assets/85767/49338fee-5276-49a2-a7fa-f1ee5a34a93c) </details> I noticed btw that there is no timer any more when VPN is disconnected, only _Reconnecting_ constantly shown. Any connection problem shouldn't influence main window - local database should always work. Even without local database (which is currently not possible), we should see remote database names ASAP. Logs shows that it tries to connect to Github among other things, probably to check latest version? <details><summary>details</summary> [1Remote.log_20230704.md](https://github.com/1Remote/1Remote/files/11951989/1Remote.log_20230704.md) </details>
kerem 2026-03-01 17:19:24 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@VShawn commented on GitHub (Jul 8, 2023):

Sorry for the delay. I found a stray kitten while walking my dog on a rainy night last week, so my free time has been dedicated to taking care of the cat and dog lately.

image


The loading screen is waiting for the database to finish loading. Therefore, if the network connection is poor, it can take a significant amount of time. This is especially noticeable when the VPN disconnects, as it will wait until it times out.

So this is not a performance issue. Perhaps you can consider optimizing the loading screen to improve the user experience in such situations.

You may consider ending the loading animation once the local database is loaded, and making remote database to continue loading in the background (it was how PRM implemented in the past). However, please note that after the MySQL database finishes loading, the main view / launcher view must be refreshed. And if the user is browsing data at the moment, they will see the screen refresh, and the selected items will be lost.

I noticed btw that there is no timer any more when VPN is disconnected, only Reconnecting constantly shown.

fixed by github.com/1Remote/1Remote@fd92d0f791

Logs shows that it tries to connect to Github among other things, probably to check latest version?

Yes

<!-- gh-comment-id:1626732156 --> @VShawn commented on GitHub (Jul 8, 2023): Sorry for the delay. I found a stray kitten while walking my dog on a rainy night last week, so my free time has been dedicated to taking care of the cat and dog lately. ![image](https://github.com/1Remote/1Remote/assets/10143738/beaa2a02-b60c-4849-8d7f-07858f6be1ef) --- The loading screen is waiting for the database to finish loading. Therefore, if the network connection is poor, it can take a significant amount of time. This is especially noticeable when the VPN disconnects, as it will wait until it times out. So this is not a performance issue. Perhaps you can consider optimizing the loading screen to improve the user experience in such situations. You may consider ending the loading animation once the local database is loaded, and making remote database to continue loading in the background (it was how PRM implemented in the past). However, please note that after the MySQL database finishes loading, the main view / launcher view must be refreshed. And if the user is browsing data at the moment, they will see the screen refresh, and the selected items will be lost. > I noticed btw that there is no timer any more when VPN is disconnected, only Reconnecting constantly shown. fixed by https://github.com/1Remote/1Remote/commit/fd92d0f7916f879fe1c4ed7e40499e3eab4c67a4 > Logs shows that it tries to connect to Github among other things, probably to check latest version? Yes
Author
Owner

@majkinetor commented on GitHub (Jul 9, 2023):

found a stray kitten while walking my dog on a rainy night last week,

All is excued then :) Life before other things!

The loading screen is waiting for the database to finish loading. Therefore, if the network connection is poor, it can take a significant amount of time

Sounds like a bad design choice to me. Why is this different then any other moment of time - I don't have loading screen when network is down while using the app, nor I should have it here. We should IMO have main window imediatelly which should show all databases by default in reconnecting state.

it was how PRM implemented in the past

And if the user is browsing data at the moment, they will see the screen refresh, and the selected items will be lost.

You can fix that, its easy to remember currently selected items. This can also happen any time when the app is running.

Actually, the worst is when internet is down so it looks like Github check is producing the major problem while it should be irrelevant. When internet is up and VPN is down I get maybe 2s delay, while its 20s otherwise.

So, I think we should have it like this:

  1. Goal is to make it no difference for this case when app is starting vs running
  2. When starting, show the main window imediatelly with all databases listed in disonected state
  3. Load the databases in parallel and refresh the main window each time one is loaded

I think there is nothing we can do to prevent glitches - for example remote database could be the first one listed, so it will inevitably move the local database from view down once it is loaded (and it will load slower then the local one). Alternativelly, we can maybe wait for all databases to load on start, and then all show them at once, which I don't think is a good UI if remote loading is for some reason slow. Note that this would all be irrelevant if you adopted my way of caching data (https://github.com/1Remote/1Remote/discussions/414) in which cases all databases would be local and we would have UI glitches only if remote is substantiatelly changed from the last run, which is something that should almost never happen.

<!-- gh-comment-id:1627711354 --> @majkinetor commented on GitHub (Jul 9, 2023): >found a stray kitten while walking my dog on a rainy night last week, All is excued then :) Life before other things! > The loading screen is waiting for the database to finish loading. Therefore, if the network connection is poor, it can take a significant amount of time Sounds like a bad design choice to me. Why is this different then any other moment of time - I don't have loading screen when network is down while using the app, nor I should have it here. We should IMO have main window imediatelly which should show all databases by default in _reconnecting_ state. > it was how PRM implemented in the past > > And if the user is browsing data at the moment, they will see the screen refresh, and the selected items will be lost. You can fix that, its easy to remember currently selected items. This can also happen any time when the app is running. Actually, the worst is when internet is down so it looks like Github check is producing the major problem while it should be irrelevant. When internet is up and VPN is down I get maybe 2s delay, while its 20s otherwise. So, I think we should have it like this: 0. Goal is to make it no difference for this case when app is starting vs running 1. When starting, show the main window imediatelly with all databases listed in disonected state 2. Load the databases in parallel and refresh the main window each time one is loaded I think there is nothing we can do to prevent glitches - for example remote database could be the first one listed, so it will inevitably move the local database from view down once it is loaded (and it will load slower then the local one). Alternativelly, we can maybe wait for all databases to load on start, and then all show them at once, which I don't think is a good UI if remote loading is for some reason slow. Note that this would all be irrelevant if you adopted my way of caching data (https://github.com/1Remote/1Remote/discussions/414) in which cases all databases would be local and we would have UI glitches only if remote is substantiatelly changed from the last run, which is something that should almost never happen.
Author
Owner

@VShawn commented on GitHub (Jul 9, 2023):

so it looks like Github check is producing the major problem

No Github check is totally background and nothing to do with the loading view

https://github.com/1Remote/1Remote/blob/main/Ui/AppInit.cs#L332-L345

  MaskLayerController.ShowProcessingRing("", mvm);  // show loading page 
  Task.Factory.StartNew(() =>
  {
      if (ConfigurationServiceObj!.AdditionalDataSource.Any())
          Task.WaitAll(ConfigurationServiceObj!.AdditionalDataSource.Select(config =>
              Task.Factory.StartNew(() =>
              {
                  IoC.Get<DataSourceService>().AddOrUpdateDataSource(config, doReload: false);
              })).ToArray());
      IoC.Get<GlobalData>().ReloadServerList(true); 
      MaskLayerController.HideMask(mvm); // kill loading page 

The above code snippet is the control code for loading page. It first shows the loading page and then create threads to read data from database asynchronously.

Once all the threads have finished or if a timeout occurs, it then kill the loading page. So it's nothing to do with Github check

#414

I still stand by my previous viewpoint that data from mysql should not be cached in local files.

When starting, show the main window imediatelly with all databases listed in disonected state

I will go towards this direction :)

<!-- gh-comment-id:1627723234 --> @VShawn commented on GitHub (Jul 9, 2023): > so it looks like Github check is producing the major problem No Github check is totally background and nothing to do with the `loading view` https://github.com/1Remote/1Remote/blob/main/Ui/AppInit.cs#L332-L345 ```C# MaskLayerController.ShowProcessingRing("", mvm); // show loading page Task.Factory.StartNew(() => { if (ConfigurationServiceObj!.AdditionalDataSource.Any()) Task.WaitAll(ConfigurationServiceObj!.AdditionalDataSource.Select(config => Task.Factory.StartNew(() => { IoC.Get<DataSourceService>().AddOrUpdateDataSource(config, doReload: false); })).ToArray()); IoC.Get<GlobalData>().ReloadServerList(true); MaskLayerController.HideMask(mvm); // kill loading page ``` The above code snippet is the control code for `loading page`. It first shows the `loading page` and then create threads to read data from database asynchronously. Once all the threads have finished or if a timeout occurs, it then kill the `loading page`. So it's nothing to do with `Github check` > #414 I still stand by my previous viewpoint that data from mysql should not be cached in local files. > When starting, show the main window imediatelly with all databases listed in disonected state I will go towards this direction :)
Author
Owner

@majkinetor commented on GitHub (Jul 9, 2023):

I still stand by my previous viewpoint that data from mysql should not be cached in local files.

You are beeing stuborn now for no good reason :)

I will go towards this direction :)

Gr8, that WaitAll has to fly...

<!-- gh-comment-id:1627724848 --> @majkinetor commented on GitHub (Jul 9, 2023): > I still stand by my previous viewpoint that data from mysql should not be cached in local files. You are beeing stuborn now for no good reason :) > I will go towards this direction :) Gr8, that `WaitAll` has to fly...
Author
Owner

@VShawn commented on GitHub (Jul 9, 2023):

Let's move the relevant discussion back to #414.

<!-- gh-comment-id:1627729941 --> @VShawn commented on GitHub (Jul 9, 2023): Let's move the relevant discussion back to [#414.](https://github.com/1Remote/1Remote/discussions/414#discussioncomment-6396479)
Author
Owner

@VShawn commented on GitHub (Jul 10, 2023):

test with an offline mysql db

https://github.com/1Remote/1Remote/assets/10143738/ac5b76b8-9f44-4f08-aaec-46ff8492847b

<!-- gh-comment-id:1629007301 --> @VShawn commented on GitHub (Jul 10, 2023): test with an offline mysql db https://github.com/1Remote/1Remote/assets/10143738/ac5b76b8-9f44-4f08-aaec-46ff8492847b
Author
Owner

@majkinetor commented on GitHub (Jul 10, 2023):

Gr8. I will check out tomorrow.

<!-- gh-comment-id:1629245443 --> @majkinetor commented on GitHub (Jul 10, 2023): Gr8. I will check out tomorrow.
Author
Owner

@majkinetor commented on GitHub (Jul 11, 2023):

I confirm it works good now.

Pause is cute, certainly one way to solve the selection problem :)

<!-- gh-comment-id:1630936638 --> @majkinetor commented on GitHub (Jul 11, 2023): I confirm it works good now. _Pause_ is cute, certainly one way to solve the selection problem :)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/1Remote#2284
No description provided.