Author Topic: Delay: start-up vs switching + flexibility  (Read 4313 times)

Pieter Hulshoff

  • Administrator
  • Hero Member
  • *****
  • Posts: 1534
  • Karma: +46/-14
    • View Profile
    • Towel 42
Delay: start-up vs switching + flexibility
« on: May 10, 2017, 04:27:52 PM »
I have a dilemma:
Currently, RetroFE reads the meta database at start-up, and the collection information (roms, etc.) when entering a collection. I could:
1. Read the meta data when entering a collection; this would speed up the start-up, and make entering collections slower.
2. Read the collection information at startup; this would slow down the start-up, make entering the collections faster, but would also require a front-end restart when you add new roms to a collection.
3. Leave things as is.
Any thoughts?

Agent47

  • Global Moderator
  • Full Member
  • *****
  • Posts: 160
  • Karma: +7/-41
    • View Profile
Re: Delay: start-up vs switching + flexibility
« Reply #1 on: May 10, 2017, 04:52:45 PM »
My opinion would be 2 or 3. I would much rather have a delay at startup and smoother transitions once navigating the frontend. I'm leaning towards 2 for that reason. I don't ever make changes to roms or anything else with the frontend open and if I do I expect to restart in order to refresh the changes. I imagine those that do make changes like that and expect immediate reflection are few and far between.

bodbod

  • Jr. Member
  • **
  • Posts: 91
  • Karma: +1/-0
    • View Profile
    • Don't be a sheep, Do It Yourself !
Re: Delay: start-up vs switching + flexibility
« Reply #2 on: May 10, 2017, 05:14:02 PM »
Agreed, option 2 seems the most appropriate to me.
I suppose most of the users are not changing roms everyday and usually you would try first and restart few times if necessary...

Pieter Hulshoff

  • Administrator
  • Hero Member
  • *****
  • Posts: 1534
  • Karma: +46/-14
    • View Profile
    • Towel 42
Re: Delay: start-up vs switching + flexibility
« Reply #3 on: May 10, 2017, 05:20:24 PM »
For option 2: consider the time for switching collections, and multiply that with the number of collections. The delay may be significant.

Sent from my SM-G920F using Tapatalk


Agent47

  • Global Moderator
  • Full Member
  • *****
  • Posts: 160
  • Karma: +7/-41
    • View Profile
Re: Delay: start-up vs switching + flexibility
« Reply #4 on: May 10, 2017, 06:02:55 PM »
If it's not a pressing issue I would say leave it as is. The popularity of #2 will hinge on the amount of delay it adds to startup and that will mean implementing it to get an accurate idea. If you wanted to create a fork with #2 implemented I'd be happy to test to see the amount of startup delay it introduces. But of course that takes time/work and I don't see a problem with how it is now, although a slight startup delay to improve responsiveness in the fe would definitely be great.

In any case, I see #1 as a bad idea. Most people, including myself, prioritize the in app responsiveness over the initial startup time. So anything that adds time/lag when navigating the frontend is going to upset most.

Pieter Hulshoff

  • Administrator
  • Hero Member
  • *****
  • Posts: 1534
  • Karma: +46/-14
    • View Profile
    • Towel 42
Re: Delay: start-up vs switching + flexibility
« Reply #5 on: May 10, 2017, 06:23:32 PM »
True, though I sometimes wonder what the impact would be to read the xml on entering the collection in stead of reading it from a (much larger) database. MAME for instance takes .6s to read from the database on my machine (it depends on the size of the full meta.db database), while reading the xml may be quicker ... or not.

Problem is of course that it's trial and error. I need to spend time implementing it to find out.

Sent from my SM-G920F using Tapatalk


dustind900

  • Full Member
  • ***
  • Posts: 104
  • Karma: +9/-3
    • View Profile
Re: Delay: start-up vs switching + flexibility
« Reply #6 on: May 14, 2017, 08:07:14 AM »
Read it all at start-up.