Visual Basic/VB, dim at procedure level or module level

dim at procedure level or module level

Author	Message
Davi #1 / 6	dim at procedure level or module level I have a procedure that gets executed continuously. I dimension (DIM) 4 LONG and 4 Single variables in the procedure. Would it be better to put them at module level rather than procedure level. The procedure is reading an electronic device at a very fast rate and I am thinking that it might take time to create the variables although I would have to set these variables to 0 each time I call the procedure. I don't need to access these variables outside the procedure either. thanks for any advice, David
Thu, 28 Oct 2010 04:09:05 GMT

Ralp #2 / 6	dim at procedure level or module level Quote: > I have a procedure that gets executed continuously. I dimension (DIM) 4 > LONG and 4 Single variables in the procedure. > Would it be better to put them at module level rather than procedure level. > The procedure is reading an electronic device at a very fast rate and I am > thinking that it might take time to create the variables although I would > have to set these variables to 0 each time I call the procedure. > I don't need to access these variables outside the procedure either. > thanks for any advice, David I've heard arguments for it either way. As you are using Singles, there might be a slight difference. And you might not need to set them to zero, ie any assignment would take care of that. Why not just try it and see if you get a measureable difference. -ralph
Thu, 28 Oct 2010 04:25:14 GMT

Steve Gerrar #3 / 6	dim at procedure level or module level Quote: > I have a procedure that gets executed continuously. I dimension > (DIM) 4 LONG and 4 Single variables in the procedure. > Would it be better to put them at module level rather than procedure > level. The procedure is reading an electronic device at a very fast > rate and I am thinking that it might take time to create the > variables although I would have to set these variables to 0 each time > I call the procedure. > I don't need to access these variables outside the procedure either. > thanks for any advice, David It will take almost no time to create the variables, but it could take a little time to set them to 0. If you are doing that anyway, there would be no difference. Local value variables, such as Longs and Singles, are created on the stack in a single step, regardless of how many there are. The total number of bytes required is added to the stack pointer - voila, variables created. For things like strings and objects, 4 byte pointers are created the same way at the same time.
Thu, 28 Oct 2010 07:51:45 GMT

Michael #4 / 6	dim at procedure level or module level Quote: > It will take almost no time to create the variables, but it could take a > little time to set them to 0. If you are doing that anyway, there would be > no difference. Local value variables, such as Longs and Singles, are > created on the stack in a single step, regardless of how many there are. > The total number of bytes required is added to the stack pointer - voila, > variables created. For things like strings and objects, 4 byte pointers > are created the same way at the same time. It's been while since I've looked at VB6 disassembled but from memory local variables will start as registers and might be pushed to the stack. In answer to the OPs question, I doubt it will improve speed, generally communication with your external device will take most of the time. It could even reduce speed as the variables might not be in registers any more.
Thu, 28 Oct 2010 11:43:26 GMT

Ralp #5 / 6	dim at procedure level or module level Quote: > > It will take almost no time to create the variables, but it could take a > > little time to set them to 0. If you are doing that anyway, there would be > > no difference. Local value variables, such as Longs and Singles, are > > created on the stack in a single step, regardless of how many there are. > > The total number of bytes required is added to the stack pointer - voila, > > variables created. For things like strings and objects, 4 byte pointers > > are created the same way at the same time. > It's been while since I've looked at VB6 disassembled but from memory local > variables will start as registers and might be pushed to the stack. > In answer to the OPs question, I doubt it will improve speed, generally > communication with your external device will take most of the time. It could > even reduce speed as the variables might not be in registers any more. Local variables or auto variables are placed on the stack. However, one or two may occasionally be placed in the register due to optimization. (Which is one reason to avoid a 'global'.) In some context one might profit from some variables to be declared as Static. "Thought experiments" in these cases are seldom useful. It is best to test. <g> -ralph
Thu, 28 Oct 2010 12:19:40 GMT

Mike #6 / 6	dim at procedure level or module level Quote: >I have a procedure that gets executed continuously. I dimension (DIM) 4 >LONG and 4 Single variables in the procedure. > Would it be better to put them at module level rather than procedure > level. The procedure is reading an electronic device at a very fast rate > and I am thinking that it might take time to create the variables although > I would have to set these variables to 0 each time I call the procedure. > I don't need to access these variables outside the procedure either. If these variables don't need known outside the procedure, keep them local to the procedure. It's much more important for them to have proper scope than to worry about how long it takes to "initialize" them (which is likely very negligible and probably not even measurable). -- Mike Microsoft MVP Visual Basic
Fri, 29 Oct 2010 07:15:22 GMT

Page 1 of 1

[ 6 post ]