Title: Speeding up XXHE UI performance Post by: Eric on November 13, 2012, 10:45:26 pm If you like to move your XXHE UI experience to a whole new level of fast response, you should try the following:
How to make a ramdisk in windows 7 - YouTube: http://www.youtube.com/watch?v=zrecoX2nsOM Basically you define your pagefile running in RAM. If you like to use RAM as your XXPlay disk, I don't believe it can work. However I didn't try. Cheers, Eric Title: Re: Speeding up XXHE UI performance Post by: PeterSt on November 14, 2012, 09:19:36 am Hi Eric,
It is a good idea - to some extend; I thought of this myself often, but there's some theory in me which tells it possibly doesn't work. But it depends a bit on how the OS treats the memory *excluding* the RAMDisk area. So : Normally, the amount of memory you have is used to create the page file size. You can define it yourself all right (larger and smaller), but normal optimum is the size of your memory. Thus, have 16GB of memort requires 16GB of page file. Yea, that won't work eh ? But, it does work when you designate 8 GB to the RAMDisk and next the OS sees it is the other 8GB as workspace only; Then things will fit. I never tried this, but since you can allocate less to the page file (than the memory size) anyway, it's worth a try at least. The Playback Drive will also work; all it needs is another partion for it on the RAMDisk. So, split it into two positions, one for the page file and one for the RAMDisk and that will work. It becomes obvious, of course, that even with 16GB of memory we won't get there much. So, theoretically 1GB could be sufficient for the Playback Drive, but only temporarily. I mean, it doesn't take much to exceed that 1GB and it doesn't go by putting more than 1 album in the Playlist (and play Unattendedly). There is more to it, and it needs you to free the space regularly (say after each album played to be on the safe side). This is the [C] button. Still we will run short of memory when 8GB is available, we allocate a higher SFS *and* we needs space for the Playback Drive. So, when this latter is 1GB, there's 7GB left for the page file, which implies 7GB of real work space is available. Not 8. So, now we have to make the real work space 7GB and the RAMDisk 9. Well, sort of, because now the Playback Drive can be 2GB (can you still follow). But when the above works, set your SFS Max to a lower value, and it will be OK. So, with 7GB of memory, an SFS Max of 250 or so for sure will be workable. It is a kind of obvious that nobody tried this thus far (I think) because with the RAMDisk software we used, this needed a payed version (otherwise limit is 4GB). Maybe today (or with Windows 8 ) this can be different. But also : today it is NOT crucial that an image of the RAMDisk can be saved. And this will give more flexibility to the choice of the RAMDisk software. Lastly, speeding up XXHighEnd's UI etc., will only work really well when XXHighEnd is in that RAMDisk area. So, like we used to use it. Regarding this : it can easily be in the partition of the page file. But careful now, because your XX folder will easily need as much (album) data as the Playback Drive does. This can NOT be avoided and is part of the whole (SQ) trick. It still might work with the real lower SFSs, like 60 or less. So yes, good idea, but too awkward for me where I'm not even keen on finally obtaining more memory for my audio PC (8GB only). But for you out there ... I'd try it. A final note : It is not so that XXHighEnd needs more speed or anything, unless we talk about a first startup (yes, it really got slower since the Scaling and stuff). However, an on par system is assumed. What I want to say is : don't ever think that you will be able to improve on things with a real slow processor (laptop comes in mind); you will probably imply counterproductive things since now the processor gets more overloaded; this happens when things become memory operations with high demand, which otherwise are "squeezed" while waithing for disk IO. One example : The page file's most demanding thing is the writing to it (which always happens for everything in memory). But, this can be a slow thing (less priority). Here, the disk IO automatically makes this slower, which means that thge CPU needed for it is spread over (more) time; When the page file is in memory, all happens 100% the same (with the addition of writing to the RAMDisk which now also is memory) except for now all being as fast as the CPU can bear. But now it will interfere with anything else we dedicated the CPU for ... in spike mode. Peter Title: Re: Speeding up XXHE UI performance Post by: nik.d on November 14, 2012, 10:01:59 am Very frequently SSD disks are assigned for pagefile duties.
This speeds up computer response enough plus it's easy to create pagefile same size as RAM. Memory is the fastest option but I would not use it for paging - in XXHE context. My 2c Title: Re: Speeding up XXHE UI performance Post by: Eric on November 14, 2012, 02:26:36 pm Peter,
Thanks for you extensive comment. Since I just started to use the RAMdisk as the (only) pagefile, I do not have any final judgement on every effect of it. What I *do* know is that my userexperience with the XXHE UI really got a boost from it. Just for the heck of it, I like to invite others to invest 15 minutes to give it a try, and see what happens. Cheers Eric |