Question - Includes over full Macro

[Warl0ck45]

I am curious on if there is a performance difference between a macro having all the lines of code contained within as opposed to having a series of includes, as far as MQ is concerned.

For instance having a general include for say follow, camp, ect... another for teleporting... another for giving items to people... another for self buffing... another for doing buffs on others.... as opposed to a single macro

For example, have an include that has the "port to" sections for druid or wizard, which only need be loaded when running those classes, instead of loading for all classes simply because it is part of the overall macro.

I am sure this has been asked before but failed to find the answer. And while in theory there ought to be no difference, reality might be different =)

 

[Teichou]

it can slow down a macro like kiss. also people won't understand they need the inc files to run said macro and could lead to more confusion.

 

[Sic]

it can slow down a macro like kiss. also people won't understand they need the inc files to run said macro and could lead to more confusion.

is this true? I was under the understanding that includes don't slow down anything, as it just adds "Subs" to the memory (assuming we're talking about the sub being inside an include versus inside the main file

 

[Teichou]

is this true? I was under the understanding that includes don't slow down anything, as it just adds "Subs" to the memory (assuming we're talking about the sub being inside an include versus inside the main file

that was my understanding....in smaller macros it can speed them up...in bigger ones like kiss it could slow them down....i'm probably very wrong...

 

[Sic]

that was my understanding....in smaller macros it can speed them up...in bigger ones like kiss it could slow them down....i'm probably very wrong...

I mean, everything is loaded into memory when it is started up, then accessed from there - a sub in an include would be treated as if it was the main file... not sure where the idea that it would slow anything down would come from

 

[Teichou]

Something about run times?

 

[Sic]

@Knightly or @ChatWithThisName @kaen01

Can we get some infos puleez

 

[Knightly]

The cake is a lie.

There is not a performance difference. The macro engine doesn't care how many files you separate out, when you're running the code it's all stored the same in memory.

 

[Teichou]

so why do we not split up big macros more?

 

[Knightly]

The issue used to be one of distribution. It was easier to distribute one file than many. But with git and the RG updater that becomes less of a problem. Still, one file was easier to distribute than a bunch -- probably just a holdover.

 

[ChatWithThisName]

There's a few reasons that people have a personal preference not to split the macros into smaller files.

A). There's no performance difference.
B). Keeping track of multiple files can be a nuisance.
C). In the case of includes, you typically separate things out if you intend to use the include for multiple macros, or simply for structure.
D). We're Lazy. Having includes in a macro, when one of the best options for modifying a macro is Notepad++, which doesn't really allow for finding functions in include files easily. If you're not familiar with the structure will cause issues when attempting to navigate the macro. IE: You can't just CTRL+F "Sub SomefunctionName" to find the definition of a Sub. For the sake of ease, it could be ommited for that reason alone.
E). You started the macro having no intention of it getting "This big" but later on down the line you had no desire to start breaking things down into includes despite the potential advantage of having the files be modular, or structured better.

B, D, E are my faults when it came to macros.

 

[jande]

There's a few reasons that people have a personal preference not to split the macros into smaller files.

E). You started the macro having no intention of it getting "This big" but later on down the line you had no desire to start breaking things down into includes despite the potential advantage of having the files be modular, or structured better.

Thanks for the laugh !

When I started I had under 900 lines it is now up to 1632 and growing. then I have 3 little helper macros that use the same copied functions which I have to move to an include but laziness prevents that atm. After all is said and done would end up with over 2000 lines.

 

[ChatWithThisName]

I've been breaking things out of my plugins into a library for a while now. Had I not done that each plugin would be over 6000 lines each and I'd have to maintain about 4800 duplicate lines of code for each plugin. There comes a point where becoming modular make sense from the perspective of the programmer. Just a matter of doing it. I believe when I first created the library I stripped about 3k lines of code from each plugin. I've managed to keep the repetitive stuff down to a minimum at this point.

Another thing I find is generating a function for a commonly completed task is also a great way to reduce the amount of lines of code I'm obligated to change/maintain. You might write a block of code thinking that's the only place you'll use it, only to find that you need it for a lot more things later on down the line.

I spend a lot of time with my plugins, but every now and then I have to stop adding features and just go through it all and try to reduce the amount of logic that is repeated.

 

[Sic]

@Denethor might be able to chime in with his explore.mac utilizing .include files --- makes development and expansion modular and neatly organized

 

[vsab]

Refactoring Home Page

Introduction to the technique of refactoring and online catalog of refactorings

refactoring.com

 

[ChatWithThisName]

Small steps and frequent testing is my motto. Haha.

Nothing in the summary of that was wrong that I could see. Sounds like my day to day haha.

 

[Teichou]

There's a few reasons that people have a personal preference not to split the macros into smaller files.

A). There's no performance difference.
B). Keeping track of multiple files can be a nuisance.
C). In the case of includes, you typically separate things out if you intend to use the include for multiple macros, or simply for structure.
D). We're Lazy. Having includes in a macro, when one of the best options for modifying a macro is Notepad++, which doesn't really allow for finding functions in include files easily. If you're not familiar with the structure will cause issues when attempting to navigate the macro. IE: You can't just CTRL+F "Sub SomefunctionName" to find the definition of a Sub. For the sake of ease, it could be ommited for that reason alone.
E). You started the macro having no intention of it getting "This big" but later on down the line you had no desire to start breaking things down into includes despite the potential advantage of having the files be modular, or structured better.

B, D, E are my faults when it came to macros.

I can see all of this....so no difference in how it fast it runs that is a good thing....alot of my info is so outdated...or just wrong....lol...I myself like the idea of splitting all the big macros down into inc files!

 

[Denethor]

I broke Explore.Mac out into inc's for the modularity itself. So if I wanted to patch the SoV route after release, I could release THAT file and not have to have folks update everything. I broke out combat to a separate inc because I knew I'd have a crappy combat sub myself, but others might write a better one. It just make certain things easier and more organized as Sic mentioned.

 

[eqmule]

I prefer one big file because it makes it easier to just have to open the one instead of having to search multiple for subs. Same reason why i keep my conditions in the same ini.

 

[Sic]

I prefer one big file because it makes it easier to just have to open the one instead of having to search multiple for subs. Same reason why i keep my conditions in the same ini.

well to be fair don't you use includes for your macros plus your mission stuff? like anniversary missions? would be much harder to do without includes, right?

 

[eqmule]

Yes i did do that. I still do prefer not to do it like that but when the macro isn’t mine i add includes to extend it, that carried over to muleassist as well but it ts not what I prefer.

Includes has their place but i have seen macros that use 20+ includes, it’s a nightmare to debug them.

 

[kaen01]

kiss is one of those plugins that could benefit from being divided into a main controller macro, and several includes
like the combat routine could be an include, then other macro writers could just include that for combathandling, for their own macros and mission macros and what not.

one can argue if you can divide up your ginormous macro into a few very specialized steps, like pulling, combat, mezzing, having those as includes could make things easier for you, and could improve the over all macro community at the same time.

but i also sorta agree with eqmule, and the idea that chat has, is to have repeated functions in an include, so you dont have to rewrite it over and over again every time you make a macro is a good idea, sorta like a tool box of little functions and stuff.

 

[Warl0ck45]

^^^^^

I like how IHC is doing his "class specific" set ups to better take advantage of X class's abilities. For example, Bards are just too utterly different and need their own set of logic when doing near anything. But at the same time generic "follow me, hand in this, camp here" style stuff or even chat monitoring commands would obviously be able to carry over.

While I can certainly see the benefits of "have all the code in one spot" to make it easier to track down bugs as opposed to having 4-10 windows open...I would hope that multiple macros sharing the same includes would help highlight the problem (for instance spellroutines.inc or wait4rez.inc or quickbeg.inc) but that would be dependent upon the include being well written enough folks can use follow the logic, and of course multiple macros using it =)

It appears that, whether the macro is 1 file or 60 the result is the same as far as results in operations. Its the amount of overall lines of code more then the amount of files that is of greater concern.

Thank you all for the assistance =)