Procedures and modules: efficiency question

[MikeLeBen]

I have a simple question, the answer to which might be complex though:

"is it better - in terms of efficiency (overhead, computing time) - to have more procedures in one module, or to split them among different modules?"

I am not considering code clarity here, but the machine perspective instead.

 

[DJkarl]

This is opinion based on my experience, but I would consider code clarity first and foremost. The amount of processing time difference between having all code in one module or breaking procedures out into seperate modules has not been noticeable to me. That is assuming you could have all your code in one module, there are limitations to number of lines and procedures allowed in a single module. Now there might be some minor differences when referring to class modules vs normal modules, mainly because you have to create a class object first before you can call the methods of the class, but in terms of having 5 functions in one module, or 5 functions in 5 modules, the time to call each one has little or nothing to do with the where they are located.

 

[SteveH2508]

I believe it used to be an issue in earlier versions of Access where modules were loaded 'on demand' and any potential call's module was loaded as well. I think that later versions of Access are more efficient in this respect so it is not so critical now.

 

[gemma-the-husky]

In some languages you can control memory loading, and set modules that wouldn't interfere with one another to overlay in memory - which used ot matter when there was a 640K limit.

I think as computers get more and more memory this is less relevant, and anyway, you can't do it in Access.

So I shouldn't think it matters.

 

[Galaxiom]

It is really mostly about scope. If a function is only used by other functions and procedures then declare them as Private in the same module. This way they don't get mixed up with functions that *might* even have the same name in another module.

It can be surprisingly easy to inadvertently reuse a name for a generic function in a large project especially when reusing modules from earlier work. It important to take great care with scope.

This is really much like is done with Class modules. I like custom Class modules for the same reason because they rigidly control the identity and scope of their private functions and public methods.

For Public functions I tend to group them by purpose. For example I have a module with functions to load, sort, filter and resize listboxes. Another with functions to dynamically space out and align controls.

When working with reading text files I put all the functions related to that activity in a separate module.

Another module holds Global constants for all the ADO enumerations, very useful for late binding.

 

[MikeLeBen]

Thanks for all the replies.
I would say it's all about the programmers' style and personal preference then.