Selection of efficient memory allocators

[elfring]

Would you like to reuse an advanced memory allocator like the following?

• Hoard
  
• nedmalloc
  
• ThreadAlloc
  
• McRT-Malloc
  
• BGET

Will you notice a positive effect on your application?

[jeroen]

I must admit not knowing about malloc replacements like these. I know of debugging malloc libraries, but that's something else. I've spend 2 hours with hoard and nedmalloc, the first I cannot get to link, the second does not show any improvement.

I think maybe these replacements are only for multithreaded programs. The JkDefrag library is not multithreaded (the JkDefrag.exe program is). So I think these libraries will not do much for JkDefrag.

[elfring]

Is there anything wrong with the usage description?

[jeroen]

Is there anything wrong with the usage description?

Yes. They do not work for me. I have tried several things, but keep getting error messages. I am sure it's possible somehow, but I have had to give up for lack of time. Perhaps you would like to give it a try? I'd be most grateful if you can tell me exactly what changes I have to make. Please note that I compile JkDefrag via the "Makefile" (not the Visual environment), and that distributing extra DLL's with JkDefrag is not an option for me at this time (perhaps in the future, but not just now).

[elfring]

I've updated your "Makefile" on my computer. I can compile and link with "winhoard" at least.
I have troubles to build Hoard from its sources on my system. Did you notice different obstacles?

[jeroen]

I've updated your "Makefile" on my computer. I can compile and link with "winhoard" at least.

Quote from my previous answer: "I'd be most grateful if you can tell me exactly what changes I have to make."

[elfring]

Can you see the differences from the file that I've mailed to you?

[jeroen]

Can you see the differences from the file that I've mailed to you?

Thank you very much, I appreciate it. The way you have linked Hoard into JkDefrag requires the Microsoft MSVCR90.dll to be installed on the computer where JkDefrag is to be run. It's not installed on my computer, so I cannot run the JkDefrag+Hoard version. And as I said before "distributing extra DLL's with JkDefrag is not an option for me at this time (perhaps in the future, but not just now)."

Also, have you tried a speed comparison? Does Hoard make JkDefrag faster? Only the analysis phase should be affected (if at all). The other JkDefrag phases do not allocate new memory and should have the same speed.

[elfring]

The way you have linked Hoard into JkDefrag requires the Microsoft MSVCR90.dll to be installed on the computer where JkDefrag is to be run.

I rebuild the library "winhoard.dll" on my computer. This changed the dependency to "msvcr80.dll".

Does Hoard make JkDefrag faster?

Yes - there is a measurable difference.

Code:

16:11:05 Commandline argument '-a' accepted, optimizemode = 1
16:11:05 JkDefrag v3.26
16:11:05 Date: 2007/09/28
16:11:05 NtfsDisableLastAccessUpdate is inactive, using LastAccessTime for SpaceHogs.
16:11:05 Starting JkDefrag for 'E:'
16:11:06 Phase 1: Analyze
16:13:22 Finished.
16:13:22 - Total disk space: 186828976128 bytes (174.00 gigabytes), 45612543 clusters
16:13:22 - Bytes per cluster: 4096 bytes
16:13:22 - Number of files: 789844
16:13:22 - Number of directories: 97050
16:13:22 - Total size of analyzed items: 180399112192 bytes, 44042752 clusters
16:13:22 - Number of fragmented items: 21, 0.00% of all items
16:13:22 - Total size of fragmented items: 3933810688 bytes, 960403 clusters, 2.18% of all items, 2.11% of disk
16:13:22 - Free disk space: 3291832320 bytes, 803670 clusters, 1.76% of disk
16:13:22 - Number of gaps: 74
16:13:22 - Number of small gaps: 21, 28.38% of all gaps
16:13:22 - Size of small gaps: 651264 bytes, 159 clusters, 0.02% of free disk space
16:13:22 - Number of big gaps: 53 (71.62% of all gaps)
16:13:22 - Size of big gaps: 3291181056 bytes, 803511 clusters, 99.98% of free disk space
16:13:22 - Average gap size: 10860.41 clusters
16:13:22 - Biggest gap: 1868480512 bytes, 456172 clusters, 56.76% of free disk space

Code:

16:14:23 Commandline argument '-a' accepted, optimizemode = 1
16:14:23 JkDefrag v3.26.1 (with Hoard)
16:14:23 Date: 2007/09/28
16:14:23 NtfsDisableLastAccessUpdate is inactive, using LastAccessTime for SpaceHogs.
16:14:23 Starting JkDefrag for 'E:'
16:14:24 Phase 1: Analyze
16:16:29 Finished.
16:16:29 - Total disk space: 186828976128 bytes (174.00 gigabytes), 45612543 clusters
16:16:29 - Bytes per cluster: 4096 bytes
16:16:29 - Number of files: 789845
16:16:29 - Number of directories: 97050
16:16:29 - Total size of analyzed items: 180399112192 bytes, 44042752 clusters
16:16:29 - Number of fragmented items: 21, 0.00% of all items
16:16:29 - Total size of fragmented items: 3933810688 bytes, 960403 clusters, 2.18% of all items, 2.11% of disk
16:16:29 - Free disk space: 3291832320 bytes, 803670 clusters, 1.76% of disk
16:16:29 - Number of gaps: 74
16:16:29 - Number of small gaps: 21, 28.38% of all gaps
16:16:29 - Size of small gaps: 651264 bytes, 159 clusters, 0.02% of free disk space
16:16:29 - Number of big gaps: 53 (71.62% of all gaps)
16:16:29 - Size of big gaps: 3291181056 bytes, 803511 clusters, 99.98% of free disk space
16:16:29 - Average gap size: 10860.41 clusters
16:16:29 - Biggest gap: 1868480512 bytes, 456172 clusters, 56.76% of free disk space

If approximately 11 seconds are a remarkable improvement on my system, that seems to be an other matter. :wink:

Only the analysis phase should be affected (if at all). The other JkDefrag phases do not allocate new memory and should have the same speed.

I have got the same impression.

[jeroen]

I rebuild the library "winhoard.dll" on my computer. This changed the dependency to msvcr80.dll.

Nope, still no good. Then I would have to distribute msvcr80.dll with JkDefrag, and that requires a Setup program. I've been meaning to create an installation program for JkDefrag, but have no time for that now. And before you ask, yes, I know about setup generators such as InnoSetup and WIX.

Yes - there is a measurable difference.

Nice! Eleven seconds out of 2 minutes is not that much, but still nice. I have put it on my list to take a closer look at malloc replacements in the future.