performance Launchbox hogging system resources and responsive issues...

[Tex8503]

So  - Let me start off by saying - I love launchbox and bigbox. They're great and pretty much do everything I want. I own a license.

That being said, there's some serious performance problems that need to be addressed (and I say this as someone who helps write software).

I'm running an emulation only box:

Win 10 64bit build 19044
Intel Core i3-8121U 2.20 ghz (4 cores)
8gb of ram
Radeon RX 540
1TB NVME drive

It's an Intel Nuc Gen 8 and its been slaying pretty much everything pre-PS2.

It has 14,288 games at the moment.

Launchbox brings it to it's knees. About a minute after start up, it consumes ~2gb of ram. I left the system up for days with Launchbox running and this climbed to ~7gb basically consuming 99% of the system memory.

It doesn't seem to matter if I'm in list view or images view... it eats resources all the same.

It also doesn't seems to 'lazy load' things by not loading things that aren't on screen...  I'm also wondering if it uses a database, ala sqlite - because ~14,000 records should not take ~2 gig of ram... On top of being 'slow' - there's also resource leaking issues it seems over time...

Is there any word on performance improvements coming? Honestly, this is more important to me than any  feature that could be added.

[Retro808]

The team is always working on performance improvements. Definitely should not see upwards of 6gig of RAM use. 2 of my cabinets are Ryzen 3200 CPU with 8GB of RAM and have no issues running LB or BB. Largest my system will eat on memory is around 1700MB. It usually hovers in at around 900-1200. I know we have had random users here and there with lighter spec systems having similar issues, usually this is with BB though due to how much data BB puts in RAM.

Safe to assume your Windows and all your drivers are up to date? I link the thread on our moderator discord with the 2 devs so hopefully when they are working in they next couple days one can chime in.

[Tex8503]

Appreciate the quick response!  

TBH - even the 1-2gb worth of memory usage seems high to me. Assuming it's loading all of the metadata and such into memory, maybe this is right, but even when filtering platforms or changing views between image or list, the memory usage doesn't change, which leads me to believe it's leaving everything in memory at all times, which seems like it could dramatically hurt folks with less memory. I'm just guessing without being able to look at the code and how its managing data - so I could be way off.

One thing to note: this is happening for me in Launchbox, not Bigbox. I'd need to do some more checking on Launchbox on this system  to confirm, but I'm trying to use Launchbox to get the dataset right.

I am running windows 10 still, haven't made the jump to 11 for various reasons, but all other updates are applied and my drivers are up to date.

I just poked at my data folder and it seems everything is stored in XML... ~100mb total worth in my case. Curious how the software is handling this... seems a stretch that ~100mb balloons to 1-2gb.

Not trying to backseat develop, but would be interested in hearing about the technical challenges the  dev team is facing here and would love to provide ideas.

Edited January 9, 2022 by Tex8503

[C-Beats]

Hey ya Tex. I've not seen RAM usage hit that high before on LaunchBox, but typical reasons for the usage getting higher than normal is because you have ran several imports and media grabs (namely from EmuMovies) since the application has been open. We do keep a lot of information in memory from both the files in the data folder but after running the first import we keep most information from the metadata file in memory as well as some response from third party sources like EmuMovies. This is done to drastically improve the amount of time subsequent imports take to run and reduce the amount we are hitting third party APIs. There are some things we would like to look into moving forward to help with the disposal of those but typically they don't become prohibitive to the user and so they have had to take a backseat to more pressing matters. That being said we do realize that performance isn't as good as it can be in several area's of the platform and are always working to improve things. In fact the current beta that is out right now is almost exclusively performance related changes. That being said it's worth pointing out while we monitor the memory consumption typically isn't the first metric we optimize against. Load time and UI performance are the first two metrics we shoot for generally speaking. If memory usage has to suffer for those two items (within reason of course) we typically lean for better load time and responsiveness because this is what the user feels the most. At this point in time memory is the cheapest resource on the computer and so optimizing against that as a heavy first place metric seems a bit misguided to me.

[Tex8503]

Makes sense.  I think I might have done media requests or imports - so I'll keep an eye on it. 

As for not optimizing for memory usage, It makes sense to prioritize UI performance and load time, but in my experience, those things are often connected - IE if you load a lot into memory upfront, you're likely to increase that first load time, but decrease all subsequent load times when doing hits for the same info; however, it's a trade off because if you've got LOTS of data in memory, then depending on how it's indexed and stored, it could be more cumbersome to manipulate and lag the UI if you're pushing the whole dataset each time rather than just the diffs between states when editing the dataset when there are changes, which would impact impacting metrics like the speed of the UI.  

I'd imagine a true database could do a lot to improve this when you query for specific keys rather than doing iterations over datasets, but I also know a change like that is not trivial.

Thank you for the conversation and humoring the ideas here.

[C-Beats]

Not sure I agree in regard to the memory use. The only time reading from a memory is slower than reading from disc is when the OS has to shunt your data from the page file to the RAM before giving it to you. Also in regards to the UI, typically (at least in WPF) the cause for delay is CPU related (waiting for main thread so you can render the menu, or the time it takes to process the data the menu is built around) or hard drive I/O related (simply takes a bit to load a resource from file).

In regard to the "true database" the only database backend that would work for LaunchBox (free to end user, and completely portable) that I know is SQLite. SQLite is nice for what it does but it's severely limited in how it stores its data in regard to data types and most of the comparison is done via strings which in C# is VERY slow, then you ALSO have the overhead over casting/serializing/de-serializing all the data you get from SQLite BACK to a data model useable by WPF. This would cause not only an increase in CPU time, but also memory (since now your data must be duplicated) and cause quite a bit of delay due to garbage collection (since those data models then need disposed) so you typically are at a net loss, more so than a gain.

We COULD add more indexes to our internal database but again, if you're already talking about a large memory footprint, adding indexes would only increase that footprint since again, you are duplicating data to make the key lookup faster. You also have to ask yourself, how OFTEN would the index be used? If not very then you've cached the data and increased your foot print for a pretty rare use case. So it definitely is a bit more of a balancing game then many would like to admit.

[Tex8503]

I think it depends on how much data you're working with, how your custom DB works, and how the updates work.

For example, if you've got 10,000 records and record 9,000 needs to be updated, if you can touch record 9,000 without seeking through the 8,999 that come before it, and then when you write the data to 9,000 - depending on when you write this to disk, you need to also need to update that record in memory - so if you can do that without the OS restaging all 10,000 records. This likely gets more complicated depending on how many tables / how complex the data model is. This example assumes 1 table - but in a perfect world, the data is organized in such a way that you've got limited data (that might be indexed) that's the most common (maybe for things like the data in list view) - then other tables for expanded data, that you only pull when the individual game is queried when you select one.

I've used SQLite before - but not with C# - but it's always been a pretty small footprint and performant... so I'm surprised the C# implementation isn't up to snuff, but i'll take your word for it!

Again, as I said before, I don't know how the data is organized - so I'm just guessing, and def not trying to armchair quarterback - if anything, just trying to challenge assumptions. SQL Server Express / LocalDB or RavenDB might also be options if someone wanted to do a POC.

I know this isn't the same, but I get PTSD from large memory databases because of a web app tied to a recipe system for a client I worked with.... the agency that build the app before us loaded the entire db into memory across multiple maps and then correlated this to flat data files to achieve a sort of 'categorization' of data without touching the MS SQL DB. This DB had 10,000+ records and the app took 5 min to start... and then was sluggish beyond what was expected. We actually found that by modifying the data in the DB and having the app call it directly actually improved performance because the memory paging took too long for what were small records - not to mention we cut the app start up time down to 5-10 secs. Btw - this was a .NET MVC 4 app.