Hi Jason,
As Heath says, it's hard to comment on why compile times/program size are what they are in your case, though I think he was drawing attention to the fact that your system design apparently grows exponentially as either increases - which can't be good.
In terms of Modules vs. "straight" Symbols I'll do my best to shed some light on things (assuming I've understood the situation correctly...):
Simpl Windows user modules are purely a convenience. They provide encapsulation of reusable logic which allows for reuse, easier/safer modification of multiple instances, code readability (one would hope!) and smaller main program size.
For each instance of your logic in your program, if you include a reference to the user module, your program file contains a single reference to the user module logic, as opposed to all of the symbols that are contained within. That would account for the huge variantion in size of your SMW file.
When you compile, simple windows reads the user module and *effectively* in-lines your module in the compilation - a new set of symbols for each and every reference. The resulting compiled program is exactyly the same - no difference in symbols/signals/processor resources. It's not like a traditional library module that has a shared code segment.
Unfortunately, I have a suspicion that Simpl Windows reads the user module each and every time it is included, which will also account for the significantly longer compile times when using masses of modules. [Possibly a contributor as to why SB takes so long to compile?]
The basic "primitive" symbols are all read into Simpl Windows at startup (part of the long program startup time!) so a program comprised of native symbols will not share that file IO overhead.
Having said that, the benefits of using modules will normally far outweigh any compile time overhead, so they're definitely a *good* thing.
If you're finding the program unmanageable or compile times are longer than you'd like, I would be tempted to look at why your design requires "Rooms * User_Interfaces" modules. Heath's suggestion of using Crosspoints should provide a much more linear growth.
Hope that helps,
Ol
