GUI Navigation is slow (normal mode)

[Imgema]

7 hours ago, Jason Carr said:

Hi @Imgema@ckp, to be honest I'm doubtful that the speed differences you were seeing previously with the 6.4 and 6.6 versions had anything to do with code differences; most likely they had to do with the size of your collection. So I'm doubtful that going back to 6.4 or 6.6 would speed things up, and for that reason I don't think we're going to get it a whole lot quicker for 6.10.

But the size of my collection is always the same since version 5.0.

 

Since the program is portable, i'd like to get version 6.4 and test it again, to see if it's indeed a change in my system that causes the lag. Is there anywhere i can download it? I know i should have backed it up before updating : /

Edited September 22, 2016 by Imgema

[Imgema]

Just wanted to say that i tested LaunchBox into a RAMDISK. This is, of course, MUCH faster even than the fastest SSD drive (like several factors faster).

I also removed most of my pictures and left only few of systems to browse. Basically, i tried to make it as fast as it can possibly go.

 

The results were, well, there was no difference. The program is exactly the same as in my mechanical HDD, with my complete collection.

 

In other words, it doesn't make a difference how fast your HDD is or how big your collection is. At least on a decent CPU. I don't know if slower systems can benefit from faster storage/smaller collections. But my i5 4670 definitely doesn't benefit at all. It runs the program as fast as it can possibly run it, despite the storage/collection size.

So the responsiveness/quickness of the program depends on the program itself and the CPU, from my testing, not the HDD or the collection size.

Edited September 23, 2016 by Imgema

[ckp]

@Imgema, that is a very interesting experiment, but with disappointing results! I was really hoping for someone to go through the process of moving everything to ssd or ramdisk and inform us of the difference observed. I have been very curious about exactly which pieces of this puzzle would benefit by running off of SSD. Now I'm not so much in a hurry to move anything from my usb 3 drive (except i do have a symlink for my image cache folder to my ssd). Ideally I want everything on my usb 3 drive and don't want to move anything off of it, but I also want good usability.

If you had LB, all games art/video, and image cache files in your ramdisk and things were still the same speed, then that is quite surprising. 

Did you really have everything in the ramdisk, including image cache and all art/video? Because my image cache is several gigs, so you must have used a very large ramdisk and have a lot of ram.

All that said, I think Jason made a huge improvement in the recent Beta builds, so he is headed in the right direction. I know it must be very difficult to make enough time to squash all the bugs, develop new code, spend time on performance improvements, read the forum posts, market the product, maintain the website, order fulfillment, etc, etc, especially if he's a one-man-team! 

 

[DOS76]

If @Imgemais running his OS on the mechanical drive then putting LB in a RAM disk or on an SSD isn't going to see improvements because the mechanical OS drive is the bottleneck I don't keep LB on a SSD I keep Windows on an SSD. If he already has a SSD for his OS then my point is moot but if not his findings don't seem conclusive to me.

[SentaiBrad]

I would test with my LB install, but it's currently over 100GB. I honestly don't want to pair it down to about 28GB. A faster hard drive will help with caching as you may suspect, but at a certain level it won't do much more. If you're on something super slow and go to an SSD or a decent USB3 drive, you would probably see a decent performance increase in certain loading, however it does come down to CPU in the end. We don't really utilize the GPU because that is actually very hard to do (we both agree that would be awesome, but he's mentioned several times how difficult that is), and things are loaded in to RAM from your hard drive as needed, so the worse these are, technically speaking you will see worse performance.  However, an SSD to an M.2 or RAM Disks, yea,you may not see as big of a performance increase because at a certain point it was already fast enough. Also, a big test is instead of copying your install then emptying it, install a brand new copy in to an untouched folder and move a completely blank and fresh install, then test an install as big as you possible can have.

 

In the end too, Jason does code the program alone. Kirsten and myself help him with everything else we can, but in nature is limited due to our skill set. I try and help him literally as much as I possibly can. Performance took a bit of a back seat for some of the big features that have recently been published, it's just a cycle. After some more performance, I believe up next is some Database improvement. I want to help him outfit it as best as we can, but probably after Retropalooza next weekend.

[ckp]

1 hour ago, SentaiBrad said:

however it does come down to CPU in the end

CPU is not a bottle neck at all for LB, at least not on my system.  I don't think CPU is an issue for the performance people are seeing.

I would love to test starting from a blank new LB install and adding all my stuff back from there, but I just don't have that kind of time myself. That is a lot of work. 

I think it's already proven that the code itself can make a huge improvement for performance as we've seen in the latest 6.10 beta builds.

If you guys had a really nasty slow test system that exhibits the slowness people are hitting, that might also be good for your debugging.

 

Edited September 23, 2016 by ckp

[ckp]

1 hour ago, DOS76 said:

If @Imgemais running his OS on the mechanical drive then putting LB in a RAM disk or on an SSD isn't going to see improvements because the mechanical OS drive is the bottleneck I don't keep LB on a SSD I keep Windows on an SSD. If he already has a SSD for his OS then my point is moot but if not his findings don't seem conclusive to me.

Actually you can have your OS on slow mechanical drive and see a HUGE performance boost running applications on very fast media. For example, I run vmware virtual machines all the time. If I store a VM on a mechanical drive where the Windows is installed or even on a different mechanical drive, the VM is very slow compared to having the VM stored on an SSD drive.

Most of that speed is because all the read/writing is happening on the ssd media even if the OS itself is running on slow media. Yeah @Imgema findings may not have enough detail to be conclusive, but they seem to be inline with what I saw when I moved my image art LB cache to ssd and it didn't seem to make a difference from being on usb 3.

 

[SentaiBrad]

It used to be that once you hit 5k in your library it would automatically start to slow down, we proved this. However, recently XML splitting has occured and caching has gotten a whole hell of a lot better, so it's murkier now. Don't get me wrong, better hardware all the way around will help period, but to what extent. The hardware requirements still sit with CPU with HDD and RAM about even in some respects. If you turn off RAM Caching for example, Hard Drive usage shoots up. The biggest spikes come from the cache generally speaking, but at a certain point between the code and the CPU a faster hard drive wont neceserilly make a huge difference if the hard drive is moving faster than the software can chug through code. I could be wrong, but I've talked to Jason about LaunchBox for over 2 years now, so I should (Hope) have my facts correct.

[DOS76]

@ckpthat makes sense for a VM kind of since all Windows is doing is hosting it and then all the reading & writing is being done on that disk, much like a weaker machine can get excellent performance from and RDP session with a much more powerful client. That's interesting I have a few Hyper-V VM's laying around and 2 spare SSD's I may try doing some experimenting with moving the VM's to a secondary SSD and see if it improves the performance. Thanks for the tip.

[ckp]

@SentaiBrad, all good points. I am certain, after Jason has some time to dig deeper into performance tuning, that he will find some ways to make a big difference on most semi modern to modern systems. It will happen.

[Imgema]

Let me detail my test a bit more.

First of all, my HDDs are all mechanical. I don't have an SSD. So with a RAMDISK test, i would be able to see the biggest possible difference.

I created a 4 GB RAM disk. Then i copied-pasted my Launchbox setup (it's portable) without the manuals or the pictures folder. Then i copied the picture folders of 3 systems (less than 2.000 pictures). The whole setup was less than 2GBs in the RAMDISK. I opened the program in the RAMDISK and refreshed the image cache. I made sure all the images were cached and then started browsing.

The performance was the same. It takes a bit less than 2 seconds to change systems in the list in both the RAMDISK or the mechanical drive. It takes a second to change games in the games list in both mediums as well. Overall, i couldn't tell i was running this on a RAMDISK. Even the image caching on startup was only a tiny bit faster.

So from my testing, in my system (i5 4670) the mechanical drive is not a bottleneck. I can't comment for slower systems though.

 

Keep in mind that it's not a complaint. The current speed of the program is acceptable. I'm just trying to clear things up about supposed bottlenecks.

Edited September 23, 2016 by Imgema

[ckp]

4 minutes ago, Imgema said:

Keep in mind that it's not a complaint. The current speed of the program is acceptable. I'm just trying to clear things up about supposed bottlenecks.

That's a great point. In the 6.10 beta builds I'm surely not complaining either! Could it be better? Maybe. But at its current speed compared to when I used 6.8 and 6.9, it is a world of difference that i truly appreciate!

[Imgema]

Just now, ckp said:

That's a great point. In the 6.10 beta builds I'm surely not complaining either! Could it be better? Maybe. But at its current speed compared to when I used 6.8 and 6.9, it is a world of difference that i truly appreciate!

It sure is. It's at least twice as fast as the previous version for me. Versions 6.4 through 6.6 were the fastest though (less than 1 second in the systems list for me, same collection) so i wonder what was so different about those and if the same performance can be achieved.

If not, it's fine really. 6.10 performance is OK. As long as it doesn't slow down later on that is

[Jason Carr]

Hi all, there's a lot of speculation going on here, so I thought I'd clarify a few things:

- CPU *is* most definitely a bottleneck for much of what LaunchBox is doing, especially when switching between platforms, searching through the collection, etc. It may not appear that way to you because of the nature of multi-core CPUs, but the biggest bottleneck when switching between platforms is definitely CPU. The faster your CPU, the faster LaunchBox will run.

- Collection size *does* matter tremendously because the larger your collection, the more CPU time it takes to search through all the games. The reason why @Imgema's test had the same results was simply because the disk was not at all the bottleneck in that scenario. The CPU is the bottleneck.

- Disk speed *does* matter tremendously as well, but primarily during loading the app and populating images. Since @Imgema tested completely without images, the disk speed requirements were basically taken completely out of the picture.

[ckp]

@Jason Carr, for cpu it sounds like you are saying that the strength of a single threaded core is most vital as opposed to gaining any advantage from multi core multi threaded cpu's. is that accurate?

so if we see, as an example, launchbox process in task manager consuming 25% cpu on a 4 core single threaded cpu system (like intel i5), that means we are bottlenecked because one single threaded core is fully pegged. i don't think i have seen that much usage on my system but i'll double check that when switching platforms by logging usage with perfmon.

i just want to narrow down if i have any bottlenecks anywhere.

thanks!

[SentaiBrad]

We did this testing a long time ago, extensively. a SATA3, USB3 or SSD is sufficient and as long as the RAM Cache is kept appropriate to the the amount of system RAM you have that should also be fine.

[Eirulan]

This most likely has been mentioned before, I haven't read all posts, but I am sure this software would benefit greatly from an actual database backend instead of relying on a XML structure... Any plans in this regard? 

[SentaiBrad]

10 minutes ago, Eirulan said:

This most likely has been mentioned before, I haven't read all posts, but I am sure this software would benefit greatly from an actual database backend instead of relying on a XML structure... Any plans in this regard? 

It has been mentioned, a lot, but changing it wont provide any signifigant increase in performance.

 

Edit: I may have gotten my answer confused with something else XML related.

[Jason Carr]

Actually, yes, a proper database backend would likely improve performance, and yes, it is planned for eventually.

[DOS76]

Many users rely on the XML to be able to edit things that aren't otherwise changeable in LB most importantly your game paths if this feature was added in to LB or even replaced with the ability to edit the DB in Access then that would be great.