The standard collector strategy (be it set up by the Falcon interpreter or by embedding applications) is adequate for average scripts.
However, some script meant to start from command line and dealing with time critical data may find the action of the garbage collector too intrusive. For example the GC may occuur at the wrong time. Other times, calculation intensive programs may generate a lot of data that they know in advance can be never garbaged during some period. In those case, having GC to scan periodically the allocated memory for released blocks is evidently a useless waste of time.
Finally, some complex scripts may even provide their own collection strategy, based on memory pattern usage that they know in advance. Starting the collection loop at time intervals, provided the memory allocation has grown at a certain rate, or hasn't grown for a certain time, may be a fitting strategy for some scripts.
A sensible usage of the garbage collection feature may boost performance of calculation and memory intensive scripts by order of degrees, and may be essential in time critical applications where some part of the process has to be performed as fast as possible.
Consider that some of the functions listed in this section may not be always available. Some embedding application may decide to turn some or all of them off for security reasons, as a malevolent script may crash an application very fast by turning off automatic GC check-and-reclaim feature and then creating a great amount of garbage. Also, the loop maximum execution time control is not present by default in Falcon command line, as the time-deterministic version of the garbage collector is sensibly slower, and it would be useless to the vast majority of the scripts.