Wish Optimize compiler so it removes unreferenced Subs & Variables Code Module

[Widget]

I often use my Code Modules composed of general purpose Subs that can be used among a variety of B4A applications. But any particular B4A application may reference only 3 or 4 subs from a code module and the code module could have 40 or 50 subs that go unreferenced.

I'd like the B4A "compiler" to remove these unreferenced Subs and variables in the APK file that it generates so the APK file is smaller and loads faster. In the B4A IDE the Logs window already knows which variables & subs are not references, so why can't the compiler not add them to the APK file?

TIA

 

[walt61]

+10

 

[sorex]

one of the problems is callsub.

It's based on passing subnames as a string so even when there ain't no direct call to the sub a call to that sub might still happen.

If variables are used in the callsub command then it gets even more tricky.

 

[Widget]

one of the problems is callsub.

It's based on passing subnames as a string so even when there ain't no direct call to the sub a call to that sub might still happen.

If variables are used in the callsub command then it gets even more tricky.

Understood. Then it means including a compiler directive around the code or sub so it does not get optimally removed, like:

#KEEP
sub x1

end sub
#END KEEP

This prevents the code between the #KEEP ... #END KEEP from being removed by the compiler.

 

[walt61]

Then again, the #KEEP idea would mean that your code modules wouldn't be truly shareable anymore, as one project might need other #KEEPs than another. Perhaps the IDE could generate a list of seemingly unused subs which can then be checked as keep or discard, for the project itself.

 

[Widget]

Then again, the #KEEP idea would mean that your code modules wouldn't be truly shareable anymore, as one project might need other #KEEPs than another. Perhaps the IDE could generate a list of seemingly unused subs which can then be checked as keep or discard, for the project itself.

You're right. I was only thinking of using the #KEEP in the app and not the code modules. But like you said, the code modules could also use #KEEP.

Another solution would be to have in the "#Region Project Attributes" an entry like "#KeepSub: Module1.X1, Module1.X2, Utils.CnvtRGB" that would inform the compiler to keep these subs and not optimally remove them. You would only need to list the subs that use subnames in a string. This allows each project to explicitly keep around the Subs that the compiler might try to remove. Each project can have a different list of subs in their #KeepSub and no changes need to be done to the code modules.

What do you think?

 

[walt61]

I like it, and hope Erel does too !

 

[JordiCP]

Perhaps it would be better an explicit DONTKEEP, instead of KEEP

This way, the default behaviour would remain unchanged. Otherwise there is a big chance that existing apps would not work directly with a new B4A version implementing this feature if they make use of callsubs as @sorex said

 

[walt61]

Oops you're right of course, @JordiCP ; perhaps in combination with a menu option or so in the IDE that generates suggested 'DONTKEEP' contents which can then be used (copy/paste) and tweaked by the developer as they see fit?

 

[Widget]

Perhaps it would be better an explicit DONTKEEP, instead of KEEP

This way, the default behaviour would remain unchanged. Otherwise there is a big chance that existing apps would not work directly with a new B4A version implementing this feature if they make use of callsubs as @sorex said

That is too much work for a lazy programmer like me.

It will be much easier to include (#Keep) the few Subs that use strings for a sub name than to explicitly exclude (#DONTKEEP) a dozens (hundred?) of regular subs that the compiler can optimally remove.

Think about the code maintenance involved.

#KEEP: Yes the programmer will have to Find all references to CallSub() that his app currently references, but once that is done he doesn't need to change anything.

#DONTKEEP: Every time a new Sub is added to a code module, every app that references that code module will need to be updated to exclude that new Sub. The #DONTKEEP list of subs will keep growing larger and larger. Maintenance will be a nightmare.

IMHO, it will be easier to maintain a list of exceptions (Subs that need to be included) rather than maintain a list of Subs to exclude which is the majority of Subs.
This "[ ] Exclude Unreferenced Subs/Variables" will be an option in the Project's Build Configuration will be turned off so it won't break anything. If you turn it on then it is your responsibility to add the exceptions to the #KEEP list.

At least that's how I see it.

 

[walt61]

That approach sounds good to me !