Back to Basics

Jun 2, 2008
42
0
#1
Since performance is often a concern for many of us, I would suggest moving much of TCC's functionality into 'licensed' plugins grouped by functionality type. I say 'licensed' so as to prevent users from grabbing those plugins and using them with TCC/LE. All 'licensed' plugins could loaded by default in a default installation.

It seems to me that many long time users continue to ask for more and more functionality and the same or increased performance. The two goals are often in direct conflict with each other. Hence a more modular approach would allow those of us who only use such functionality on a infrequent basis to run a leaner shell most of the time.

Groupings could follow the existing categories in the help for commands, variables and functions.

For example, move the monitoring commands into a monitor plugin and date/time variables & functions could be placed in a datetime plugin.

Even if this is not deemed a reasonable approach for splitting out existing functionality, please consider it for future functionality.
 

rconn

Administrator
Staff member
May 14, 2008
10,775
97
#2
Since performance is often a concern for many of us, I would suggest moving much of TCC's functionality into 'licensed' plugins grouped by functionality type. I say 'licensed' so as to prevent users from grabbing those plugins and using them with TCC/LE. All 'licensed' plugins could loaded by default in a default installation.

It seems to me that many long time users continue to ask for more and more functionality and the same or increased performance. The two goals are often in direct conflict with each other. Hence a more modular approach would allow those of us who only use such functionality on a infrequent basis to run a leaner shell most of the time.

Groupings could follow the existing categories in the help for commands, variables and functions.

For example, move the monitoring commands into a monitor plugin and date/time variables & functions could be placed in a datetime plugin.

Even if this is not deemed a reasonable approach for splitting out existing functionality, please consider it for future functionality.
This comes up periodically, but the truth is that there's much less to be gained here than people think. For example, moving the monitoring commands to a separate plugin and then not loading that plugin would only save about 10-12K in TakeCmd.dll and less than a millisecond for the load, as most of the code is in common functions used by many other commands. (And for the people who *did* want to use the monitoring commands, it would end up slowing things down since it takes longer to load and initialize 2 dll's than 1 of the same size.)

Also, the more things get moved to plugins the slower the system will be as there's more overhead in loading & calling plugins than internals.

However, I *am* planning to break out a couple of major items (like the batch debugger/ide) where there is a more substantial gain, and where the load time is not especially critical and the dll can be loaded on demand.