Custom Functionality / New Functionality / Utilities question

Question

Hypothetical question for everyone :
If you could change anything about HFM or FDM, what would it be and why?
If you could have any new features / utilities / tools what would they be and why?

Answer 1

Tony,
The 2 GB limit your are referring to is most likely the User mode virtual address space limit which is not .NET specific and affects any 32 bit process in windows
User-mode virtual address space for each 32-bit process
Limit in on X86 - 2 GB (3 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE and 4 GT)
To get the 3GB, you would have to alter the executable PE header to enable the flags referenced above.
This is also referred to as 4-Gigabyte Tuning ( http://msdn.microsoft.com/en-us/library/bb613473(v=vs.85).aspx)
Limit in 64-bit Windows
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default)
4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set
For a complete memory breakdown (and a brutal headache from trying to memorize all of these requirements), please see : http://msdn.microsoft.com/en-us/library/aa366778(v=vs.85).aspx#memory_limits
.NET does; however, have some memory limitations that can cause headaches for developers and users of their programs.
The .NET limitation is not a 'per thread' or even 'per program' limitation, rather it's a 'per object' limitation. A heap object cannot exceed 2GB of contiguous memory. (no longer an issue with 64 bit versions). An example of this would be if you created an array object that would hold all records from an FDM file. If you had a data load file that was > 2GB AND the software were to load all of that into one object (say array or file object), then you would have a problem.
With that said a couple comments :
- Situations where needed more than 2GB per object are VERY RARE.
* In 32 bit Windows environments, .NET would almost never be the limitation as the process is limited to 2GB and after overhead, there wouldn't even be 2GB of memory left for .NET limitation to become the issue.
* In 64 bit Windows, not an issue anymore.....
- Are you REALLY hitting the 2GB limit?
* Pointed out earlier, the limit is up to 2GB of contiguous space. Perhaps due to a lot of instantiating/releasing of objects, the address space is fragmented and the most you can allocate is much less than 2GB?
* You may also not be releasing other objects properly which would reduce the amount of available memory. It could be that the current .NET code has poor memory management and was just trusting Garbage collection to eventually clear everything up? For basic programs, this would work just fine. For something that could potential push the upper limits, this wouldn't work so fine .....
* To look at both of these scenarios, you'd probably want to make use of the CLR Profiler tool as this could answer some questions.
- There are workarounds for 2GB limit in Win 32 that are not that difficult to implement! If the FDM code base is relatively clean and this is "the" issue, I'd be curious to understand why they are not looking at work arounds? They could create a few 'memory manager' classes and plug everything into those and keep on trucking.
Anyway, I find it implausible they are going to rewrite FDM simply because of a 2 GB .NET limitation. It could be a factor (especially if the base code is ugly), though.