Have you used PrimoCache (used to be called FancyCache)?

[NoelC]

Anyone use PrimoCache (aka FancyCache)?  If so...

 

Is it reliable?

 

How much did you find it to benefit your normal operation?

 

I have a lot of RAM and even though I have a high performance I/O subsystem I have received the suggestion to try this product to boost performance even more.  I've been experimenting with it on a VM and the results are fairly impressive, especially in that it's quite smart about not actually writing temporary files to the disk.

 

-Noel

[osRe]

Never heard of it.

[NoelC]

I tried it out on a test system.  It makes impressive improvements in benchmark results, BUT...

 

It doesn't actually speed up the normal operations I do:  Starting big applications like Photoshop a second or third time is NO faster, and software builds with Visual Studio - which I always figured are I/O bound - are NO faster.  Basically, block-level cache is ineffective considering the Windows file system cache is already on duty.

 

All a block level cache like PrimoCache really does is fool the benchmarks by inserting a RAM cache below the direct I/O calls, but it comes with baggage:  It permanently blocks off a big chunk of RAM and what's worse, my test system rebooted spontaneously in the middle of the night during a backup.

 

My conclusions, given a system with high I/O hardware performance:

 

• There were no measurable practical speed advantages to using it to do the normal I/O-heavy operations I do.  The Windows 8.1 file system cache is already very effective.
   
• According to its own statistics, configured for "lazy writes" with a long delay, it can reduce the write load on the hardware a fair bit, but this depends on how many short-lived temporary files your applications make.  Again, the numbers are skewed by benchmarks.
   
• It is not perfectly stable.  Thus it decreases the reliability of the system to unacceptable levels.
   
• Based on before/after registry checks Its uninstaller appears to completely and cleanly remove the program.

 

The baggage is unacceptable and the benefits dubious.  PrimoCache is a non-starter for me.

 

-Noel

Edited January 10, 2015 by NoelC

[osRe]

Thanks for the info.

What do you use to compare the registry pre/post?

[NoelC]

I exported the whole thing before and after to text (.reg) files and used Scooter Software's Beyond Compare to check them against one another.  It's an awesome tool for doing all kinds of comparisons.  All our software change reviews employ it heavily.

 

-Noel

[jaclaz]

Doesn't Regshot run on Windows 8.x?

http://sourceforge.net/projects/regshot/

 

jaclaz

[dencorso]

There's also Handle Software's free Regshot 2.0 Unicode for Windows XP 32 bit/64 bit

I use v. 2.0.1.70 on XP SP3. Regretably, I don't have at hand a proper link to it to offer right away.

BTW, it's language tab says "Russian", but it's, in fact, Language Neutral (one can select the language inside it).

 

There's a preserved old homepage, which really is in Russian.

 

There are whispers of a Regshot 2.1 Unicode for Windows Vista x86 SP1... it should be in "regshot-2.1.0.28.rar", in case that has ever been released, and if so, maybe further versions have been released for the NT-6.x family, before the developers gave up. I don't know... but this may be a start.

[jaclaz]

Well, not too hidden, like:

http://sourceforge.net/p/regshot/support-requests/2/

http://www.wincert.net/forum/files/file/16-regshot2-unicode/

 

Though you need to be logged in on wincert to download files, so better get it through portableapps:

not here:

http://www.portablefreeware.com/?id=297

but here, of course:

http://www.portablefreeware.com/index.php?id=2505

 

jaclaz

[osRe]

Yeah, I'm fond of Beyond Compare. And I actually was planning to try RegShot but forgot about its existence.

Regshot 2 has a separate 64-bit build. I hate these. Particularly when there's no documentation on the difference. And probably there isn't any difference at all, since why would a simple program need x64 anyway? I always keep just the 32-bit version, but at the same time I'm left wondering, am I missing something?

[jaclaz]

I always keep just the 32-bit version, but at the same time I'm left wondering, am I missing something? 

Sure you are missing the chance of occupying without any need some hard disk space.

 

Basically four cases :

1. If you run a 32 bit "full" system you need the 32 bit version ONLY
2. If you run a 64 bit "full" system complete of the WOW64 32 bit subsystem, you need the 32 bit version ONLY as the 64 bit version would not give you any advantage besides the increased disk occupation.
3. if you run a 64 bit "advanced" PE with the WOW64 32 bit subsystem added, you need the 32 bit version ONLY AND another 32 bit PE with the 32 bit version for use on machines that won't boot from a 64 bit PE
4. if you run a 64 bit "default" PE without the WOW64 32 bit subsystem, you need the 64 bit version AND another 32 bit PE with the 32 bit version for use on machines that won't boot from a 64 bit PE

Of course case #4 will also prevent you from running a large number of useful other tools  that (rightfully) do not exist in a 64 bit version, so it is the least smart choice/possibility.

 

jaclaz

Edited January 12, 2015 by jaclaz

[osRe]

But it's not a question of EXE compatibility, but of supposed benefits to a x64 build of a program that also exists in x86. That's something the developer of the software would know best.

In the case of Registry tools, I think legacy 32-bit builds won't be able to access the 64-bit portion of the registry. But if I'm not mistaken, using newer API functions will let also 32-bit builds access everything.

Edited January 13, 2015 by shae