Will Orion and other modules be going 64bit anytime soon? I can only imagine how much that would help the program when running on a 64bit platform which is fairly common at this point.
Donald,
I've asked this question internally, and the answer is not that simple. Running in 64-bit actually adds overhead, and unless the program specifically needs the 64-bits, it's often actually slower in 64-bit than in 32-bit mode.
So the answer to your question is that it's not a priority except where is solves a specific problem. If we need a service to access more memory than is allowed by 32-bits, for instance, we might compile in 64-bit mode, but otherwise, it's not a priority.
It would seem to me, that all the Orion apps would benefit from memory footprint of a 64-bit OS. Perhaps that has nothing to do with the painful slowness of using Orion via the web interface, but it'd be nice to have more RAM and be able to use it without the sort of cheap trick of PAE.
Peter
From one of our architects:
I researched this extensively when I was having performance issues ~6 months ago. Correct me if I'm wrong but because Orion is a 32 bit application, even when it is run in 64 bit Windows, it will still have a maximum of only 2 GB of memory addressable. Right? It has something to do with the way 64 bit Windows emulates 32 bit mode for those apps that require it.
If that is correct, then the net gain is very small, as the OS would be able to run in other memory but Orion would still be limited to 2 GB. However, if they were to compile and release a 64 bit version of Orion, then it would be a whole new ballgame.
This is mostly correct. A 32-bit process is limited to a 2 GB address space even when running on a 64-bit OS. However, Orion is not just one process. It is many: NetPerfMonService can be using 2 GB at the same time that the website (w3wp.exe is the ASP.NET host process) is using 2 GB at the same time that the Job Scheduler, Job Engine, and each Job Engine Worker process (there can be many of these if necessary) are all each using their own 2 GB. And that's not even counting the Alerting Engine, Syslog, Traps, and especially SQL Server (which of course ought to be on its own box if you are even thinking about this question).
And even if it is running exclusively 32-bit processes, 64-bit Windows can productively use lots of extra RAM for disk caching. Don't underestimate that.
For some applications, > 2 GB address space is a key part of scalability. At this point, we don't believe that Orion needs it, especially considering that if a program doesn't actually need > 2 GB of address space, there is a performance penalty (not huge, but not neglible either) to using 64-bit pointers everywhere.
If you are hitting the 2 GB limit in any of your Orion processes, let's work on what needs to be tweaked to get it under control.
