| Author | Message | ||
     Pánczél, Levente Username: panczel_levente Registered: N/A |
Issue using XWF 15.0 on Vista SP1 Q6600. XWF can calculate SHA-256 using full processor core capacity with 5.5 GB/min. This works if I open the image file in a running XWF. If the file is interpreted as disk image (raw image, no compression) then hashing the disk only goes with 4.5 GB/min (acceptable perfomance drop for the extra abstraction layer). But if I open the image file via explorer (i.e. launch the image to open with XWF) then the image is automatically interpreted as disk, and hashnig is no faster that 1.5 GB/min. All these versions produce constant 25% CPU usage (1 of 4 cores completely busy). I cannot guess what might be different. | ||
| Pánczél, Levente Username: panczel_levente Registered: 1-1997 |
Now I upgraded to 15.1b2 and I can no way make it hash faster than 1.5 GB/min. Now File|open in a running XWF also fails to produce the speed XWF used to be capable of. If the problem (or the one above) cannot be reproduced then I would welcome any reference speeds! I'm testing on a 100GB uninitialized file, so I/O speed is not an issue. XWF 15.0 still does 5 GB/min on the same machine if the file is opened through File|Open or as continuation of the last session. Almost all SHA-256 computation tools I tested were at least twice faster (around 3.3 GB/min). [BTW: search for a single hash value only has the speed of about 7GB/min (which I find slow if such simple searches are optimized for string scaning).] | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
If the data does not have to be physically read from a disk (uninitalized file), with File | Open, both directly and when interpreted as a disk, I get - on a 4 1/2 years old single core Intel Celeron 2.4 GHz around 3,600 MB/min for MD5 around 2,660 MB/min for SHA-1 around 1,220 MB/min for SHA-256 - on a 1 1/2 years old Intel Core Duo 2.13 GHz around 12,700 MB/min for MD5 around 11,500 MB/min for SHA-1 around 4,600 MB/min for SHA-256 hash.dll was present in the X-Ways Forensics installation directory, otherwise hash computation is much slower. Measured with X-Ways Forensics 15.1. | ||
| Pánczél, Levente Username: panczel_levente Registered: 1-1997 |
Your hint with hash.dll showed what the problem is: both versions HAVE the same hash.dll in their installation directories. But they are not loaded. I guest XWF tries to load ".\hash.dll" since copying the file to common locations (like System32 or something in %PATH%) does not solve the problem (so standard library search paths are excluded). The only option I have is to launch XWF with a shortcut that makes the program start in its installation folder; in this case hash.dll is loaded and XWF is the fastest hash calculator ever! But I cannot make this work for context menus (e.g. Open in X-Ways Forensics) for I have no way to configure startup CWD. So shell context menu commands do not work flawless (although I see that no other DLLs are loaded on startup, except for zlib1 which is found in either case). Could hash.dll be linked just like zlib1.dll to be always found? Or could XWF set CWD to the exe's parent folder for the time it loads hash.dll? I'd love to see a note in the messages window if hash.dll was not loaded, since this situation slows down almost every work. I assume that based on the first reports opening through shell context menu has also been tested and found to work ok. Would you be so kind opening a file with "Open in X-Ways Forensics" and then find out which hash.dll gets locked by windows and tell me how you have set up that XWF finds that DLL? (I cannot get it to work neither on XP nor on Vista.) | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
I will improve future releases in such a way that hash.dll should be loaded even if the current directory of the process at start-up is a directory other than the installation directory. (FYI, whether hash.dll is loaded or not can be verified in Help | About.) |