-Visual Basic Express 2005-
I'm working on a very large accounting program that requires a few hundred variables. I'm declaring most of them publicly. Is there any information that tells how much ram strings, decimals, int16 and others take Also is there a limit to how many variables I can publicly declare in a module
Thanks in advance ![]()

How do I determine how much ram a program will use?
RobinSpicer
I think you'll find with many of the points raised - the differences may be small and only noticable if things are doing a large number of iterations. You say you work on a large application but there are normally things you can do that will make a huge difference that are not VB specific such as correctly indexed database, use of stored procedures instead of dynamically creating SQL statements on the fly each time.
The biggest thing I feel is the not reinventing the wheel - there are many thousands of methods in the .NET framework. Often you can leverage these rather than writing you own functions. Things such as copying arrays - use the .net framework function rather than writing and iterative process to copy them one at a time.
As for SQL as this is a place for huge performance differentials in approach - avoid looping and work on a set based approach rather than iterating around records. This is a common issue for programmers used to languages like C trying to implement SQL solutions. Ive seen it a number of times with loop processes in complex stored procedures that can be removed and replaced with a single SQL statement or two.
If the framework can be installed on the machine - then your probably safe to say the application will run. So that accounts for Windows 98 OS and up. I'm not saying it will run quickly but it will run.
kdubious
Ok thanks Spotty :)
I'm glad I'll be ok with a few hundred. I shouldn't need more. I'll be happy when it's finally finished
daada
Thanks ahmedilyas
So far it runs very well on my pc but I have 1 gb ram. I'll be sure to test it on slower (older) computers before I publish it. If I have any problems I'll be sure to refer to your post.
davidg12
Still, I would tripple check your design. Those couple hundred variables might better be expressed in arrays or collections of objects and graphs. It's perfectly possible that you could need them all but there may be easier ways on you. Several hundred public fields is a maintainence nightmare.
Oh and there is a page somewhere in the documentation on data types and their typical storage size.
RobotBambi
A few hundred variables !!!! , With this figure you are unlikely to encounter anywhere near the limitations of that exists. No real world limits to the number of variables you can declare in a module, I'm sure that there is a number but its probably such a large figure that its really not a limitation and the limitation is probably not on the module but rather at the process level.
As far as how much ram an application uses - this varies during the lifetime of the running application as memory is used and eventually recovered by the garbage collection process when items are inaccessible and the application is running short of resource (memory). This process runs periodically and is used to clear up memory.
Also bear in mind that memory on a windows based system is really virtual with memory being swapped in and out of memory to disk. So more physical memory you will have less swapping potentially occuring. That said more physical memory results in quicker applications as less swapping would occur but with more memory the garbage collection process will run more infrequently as there is less chance of applications running short of resource
I know that sounds like an ambigious answer - but really the answer is unlikely to reach any limitations and how much ram being used by application will vary during execution.
.
Simple Samples
just to add, be sure you are doing things effeciently to improve performance as well as using less resources, such as taking advantage of SQL Server Stored Procedures if you are using SQL Server to perform data transactions as its securer and performance will be increased also.
Make sure you only use variables you need to use and not just make temp variables or rather avoid making duplicates. For strings, try using a StringBuilder (System.Text.StringBuilder) to build your strings as they will use less memory and is the .NET way of doing things correctly and is effecient.
Try to avoid re-inventing the wheel meaning if you have a method of your own that does something, check to see if .NET has one already which would have been already specialized and effecient, so use that instead.
the list goes on....