.NET Footprint
-
Hi all, I have a concern about the memory footprint of .NET applications, especially in the thin client environment. When Winframe(which became Citrix) saw the light a few years ago, our company quickly adapt to that thin client environment, with VB5 and VB6 applications and made my development experience a breeze (wish the co would allow me to sit at home and develop). Citrix has moved on to become a very nice platform - for the company in terms of user support and maintenance and for us developers. It is a very nice thin client environment (I prefer Terminal Services as a development environment, although not so thin) and the VB6 applications is fast(thin) enough and the memory footprint of said applications is not that big - and is a positive when you have 30 odd users on one terminal server. I have just upgraded an application which was developed in .NET C# being presented to the users via Citrix. The previous app was developed in C++ and had basically the same functionality as the current version, but with the new .NET app the memory footprint nearly doubled. It is an MDI sort of application and you can open multiple documents within the application - fortunately the memory does not increase that dramatically with each opened document (it's a real time trend application). In Citrix a contiguous memory space is allocated for each user that logs on, and grows dynamically if needed. If a .NET application uses that much memory footprint, the user will run out of memory space very quickly and Citrix now has to juggle for more memory which is not that contiguous any more. I can slap in more memory and perhaps allocate more initial memory space for each user (do not know if it is possible) as a solution. But is that the right approach? Any pointers how to try to develop a rich client but as thin as possible? I'll appreciate any comments to make a decision for the future.
the confused are confused beyond confusion
-
Hi all, I have a concern about the memory footprint of .NET applications, especially in the thin client environment. When Winframe(which became Citrix) saw the light a few years ago, our company quickly adapt to that thin client environment, with VB5 and VB6 applications and made my development experience a breeze (wish the co would allow me to sit at home and develop). Citrix has moved on to become a very nice platform - for the company in terms of user support and maintenance and for us developers. It is a very nice thin client environment (I prefer Terminal Services as a development environment, although not so thin) and the VB6 applications is fast(thin) enough and the memory footprint of said applications is not that big - and is a positive when you have 30 odd users on one terminal server. I have just upgraded an application which was developed in .NET C# being presented to the users via Citrix. The previous app was developed in C++ and had basically the same functionality as the current version, but with the new .NET app the memory footprint nearly doubled. It is an MDI sort of application and you can open multiple documents within the application - fortunately the memory does not increase that dramatically with each opened document (it's a real time trend application). In Citrix a contiguous memory space is allocated for each user that logs on, and grows dynamically if needed. If a .NET application uses that much memory footprint, the user will run out of memory space very quickly and Citrix now has to juggle for more memory which is not that contiguous any more. I can slap in more memory and perhaps allocate more initial memory space for each user (do not know if it is possible) as a solution. But is that the right approach? Any pointers how to try to develop a rich client but as thin as possible? I'll appreciate any comments to make a decision for the future.
the confused are confused beyond confusion
This is the sort of comment people have been making about shared libraries for years. When C++ started to become popular people would say "My god, a Hello World program is 2MB!", and while true to some extent, it ignores the fact that shared libraries are.. well.. shared... and as the program gets larger, a larger percentage of code to library occurs. To look at it another way, how much time is saved by using shared libraries. If you put a dollar value on that, how does it compare to the costs of more memory? Given that memory is ridiculously cheap these days, it's usually a significant win to buy more memory than use less libraries. However, when you get into citrix and the like, you're now utilizing far more of the machine and it's resources than ever before. Memory is only cheap up to a point (4GB DIMMS are expensive compared to 1 and 2GB). Also, whether or not you can use a 64 bit OS for your citrix also limits the amount of resources you can give your clients. Also, i'm not sure if Citrix will share code pages between users (ie use the same shared library code segments) or whether it completely virtualizes the users space. If Citrix is smart enough to share library code between users, then it's not so much of a problem. Be aware that Task Manager lies (sort of) because it doesn't give you the whole story. It doesn't tell you what's shared and what's not, etc.. You really have to do a cost/benefit analysis, and decide whether saving money on hardware is worth spending more on software development.
-- Where are we going? And why am I in this handbasket?
-
This is the sort of comment people have been making about shared libraries for years. When C++ started to become popular people would say "My god, a Hello World program is 2MB!", and while true to some extent, it ignores the fact that shared libraries are.. well.. shared... and as the program gets larger, a larger percentage of code to library occurs. To look at it another way, how much time is saved by using shared libraries. If you put a dollar value on that, how does it compare to the costs of more memory? Given that memory is ridiculously cheap these days, it's usually a significant win to buy more memory than use less libraries. However, when you get into citrix and the like, you're now utilizing far more of the machine and it's resources than ever before. Memory is only cheap up to a point (4GB DIMMS are expensive compared to 1 and 2GB). Also, whether or not you can use a 64 bit OS for your citrix also limits the amount of resources you can give your clients. Also, i'm not sure if Citrix will share code pages between users (ie use the same shared library code segments) or whether it completely virtualizes the users space. If Citrix is smart enough to share library code between users, then it's not so much of a problem. Be aware that Task Manager lies (sort of) because it doesn't give you the whole story. It doesn't tell you what's shared and what's not, etc.. You really have to do a cost/benefit analysis, and decide whether saving money on hardware is worth spending more on software development.
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
f Citrix is smart enough to share library code between users, then it's not so much of a problem.
I share more or less the same views. I does not have an in-depth knowledge of Citrix - maybe I must ask them about the statement you made. It will be quite interesting. Just maybe there are a way to develop .NET apps for the Citrix environment. After all, MS has a share in the company. As for 64 bit development - I do not think I am there yet. I have never done an C++ development, so in a nutshell, C# is quite new to me - but I am a fast learner.
the confused are confused beyond confusion
-
Hi all, I have a concern about the memory footprint of .NET applications, especially in the thin client environment. When Winframe(which became Citrix) saw the light a few years ago, our company quickly adapt to that thin client environment, with VB5 and VB6 applications and made my development experience a breeze (wish the co would allow me to sit at home and develop). Citrix has moved on to become a very nice platform - for the company in terms of user support and maintenance and for us developers. It is a very nice thin client environment (I prefer Terminal Services as a development environment, although not so thin) and the VB6 applications is fast(thin) enough and the memory footprint of said applications is not that big - and is a positive when you have 30 odd users on one terminal server. I have just upgraded an application which was developed in .NET C# being presented to the users via Citrix. The previous app was developed in C++ and had basically the same functionality as the current version, but with the new .NET app the memory footprint nearly doubled. It is an MDI sort of application and you can open multiple documents within the application - fortunately the memory does not increase that dramatically with each opened document (it's a real time trend application). In Citrix a contiguous memory space is allocated for each user that logs on, and grows dynamically if needed. If a .NET application uses that much memory footprint, the user will run out of memory space very quickly and Citrix now has to juggle for more memory which is not that contiguous any more. I can slap in more memory and perhaps allocate more initial memory space for each user (do not know if it is possible) as a solution. But is that the right approach? Any pointers how to try to develop a rich client but as thin as possible? I'll appreciate any comments to make a decision for the future.
the confused are confused beyond confusion
-
Write in assembler, that will save you the footprint, but on the other hand with take you 1000x longer.
WPF - Imagineers Wanted Follow your nose using DoubleAnimationUsingPath
-
Erik Funkenbusch wrote:
f Citrix is smart enough to share library code between users, then it's not so much of a problem.
I share more or less the same views. I does not have an in-depth knowledge of Citrix - maybe I must ask them about the statement you made. It will be quite interesting. Just maybe there are a way to develop .NET apps for the Citrix environment. After all, MS has a share in the company. As for 64 bit development - I do not think I am there yet. I have never done an C++ development, so in a nutshell, C# is quite new to me - but I am a fast learner.
the confused are confused beyond confusion
I didn't say you had to do any 64-bit development. 64-bit versions of Windows just see more memory, and 32 bit apps (for the most part, there are exceptions) just work fine.
-- Where are we going? And why am I in this handbasket?
-
Assembler?? What's that - a tool to assemble my Meccano set? :)
the confused are confused beyond confusion
-
Hi all, I have a concern about the memory footprint of .NET applications, especially in the thin client environment. When Winframe(which became Citrix) saw the light a few years ago, our company quickly adapt to that thin client environment, with VB5 and VB6 applications and made my development experience a breeze (wish the co would allow me to sit at home and develop). Citrix has moved on to become a very nice platform - for the company in terms of user support and maintenance and for us developers. It is a very nice thin client environment (I prefer Terminal Services as a development environment, although not so thin) and the VB6 applications is fast(thin) enough and the memory footprint of said applications is not that big - and is a positive when you have 30 odd users on one terminal server. I have just upgraded an application which was developed in .NET C# being presented to the users via Citrix. The previous app was developed in C++ and had basically the same functionality as the current version, but with the new .NET app the memory footprint nearly doubled. It is an MDI sort of application and you can open multiple documents within the application - fortunately the memory does not increase that dramatically with each opened document (it's a real time trend application). In Citrix a contiguous memory space is allocated for each user that logs on, and grows dynamically if needed. If a .NET application uses that much memory footprint, the user will run out of memory space very quickly and Citrix now has to juggle for more memory which is not that contiguous any more. I can slap in more memory and perhaps allocate more initial memory space for each user (do not know if it is possible) as a solution. But is that the right approach? Any pointers how to try to develop a rich client but as thin as possible? I'll appreciate any comments to make a decision for the future.
the confused are confused beyond confusion
pierrecor wrote:
Any pointers how to try to develop a rich client but as thin as possible?
Write a fat client side app, that communicates with the server (via webservices/tcp/ip remoting).
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out now -
Hi all, I have a concern about the memory footprint of .NET applications, especially in the thin client environment. When Winframe(which became Citrix) saw the light a few years ago, our company quickly adapt to that thin client environment, with VB5 and VB6 applications and made my development experience a breeze (wish the co would allow me to sit at home and develop). Citrix has moved on to become a very nice platform - for the company in terms of user support and maintenance and for us developers. It is a very nice thin client environment (I prefer Terminal Services as a development environment, although not so thin) and the VB6 applications is fast(thin) enough and the memory footprint of said applications is not that big - and is a positive when you have 30 odd users on one terminal server. I have just upgraded an application which was developed in .NET C# being presented to the users via Citrix. The previous app was developed in C++ and had basically the same functionality as the current version, but with the new .NET app the memory footprint nearly doubled. It is an MDI sort of application and you can open multiple documents within the application - fortunately the memory does not increase that dramatically with each opened document (it's a real time trend application). In Citrix a contiguous memory space is allocated for each user that logs on, and grows dynamically if needed. If a .NET application uses that much memory footprint, the user will run out of memory space very quickly and Citrix now has to juggle for more memory which is not that contiguous any more. I can slap in more memory and perhaps allocate more initial memory space for each user (do not know if it is possible) as a solution. But is that the right approach? Any pointers how to try to develop a rich client but as thin as possible? I'll appreciate any comments to make a decision for the future.
the confused are confused beyond confusion
How are you measuring the memory footprint - working set is not a good measure...[^]
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd