Global Functions
Firstly lets narrow the options and remove the global function from the picture. Many OO purists would cringe at the thought of anything global but I would not discount anything just because it was not pure, however there are many other reasons for not using global functions. Firstly they are handled differently by the PowerBuilder environment in that you do not decide the life of a global function, each time you use it, it gets loaded in from the PBL, basically a create and destroy. Also a large function is not always loaded completely into memory so you may get multiple hits to disk. Then there is function overloading which is a great aid to development which you cannot use with global functions. All these reason are why you should not use global functions in your applications.

Ancestor Functions
Next is ancestor functions. The benefit of ancestor functions is that you can code tighter functions using the this operator, the functions are always available and they are loaded into memory as soon as the object is created. This is also their problem, if you have 100 functions and I only want to use 10 then I have 90 functions in memory that I don't want. Ancestor functions also tend to lead to sloppy spaghetti code with multiple nesting of IF statements and flags all over the place. So the golden rule is where possible do not put functions in your ancestor objects. Sometimes its unavoidable to put functions in your ancestors, for example the code to interface into a service architecture must be in the ancestors. If you must do so then make sure they follow the 90% rule. The 90% rule say that 90% of the uses of the object in our application must make use of the function otherwise its overhead and should not be there.

Non Visual Objects
Lastly we have the two types of non visual object, with and without the autoinstantiate attribute set. The best use of these two types depends on how you want to use the object and related functions. If you want to build a service object that will be used in a service architecture then you are better off with a regular non visual object without autoinstantiate. The main reason being that you cannot pass an autoinstantiate object by reference. Also you are not likely to need the primary advantage of the autoinstantiate type which is the automatic creation of the object on use.

Autoinstantiate objects are quicker to create and destroy and they also have another advantage in that they are only created when they are used. With normal NVO's you have to figure out when to create the objects, if you have complex logic with many calls to functions in the object then you would probably just create the object at the top of your script even if the flow of logic never used the object. In PB5 if you have multiple exits to the function you also need to worry about destroying the object in multiple locations. you do not have to worry about these things for autoinstantiate objects. In tests I found the same function in an autoinstantiate object was quicker to call than to create the equivalent NVO and call the same function.

Summary
To summaries, never use global functions, use autoinstantiate non visual objects for grouping related functions such as string manipulation or Word integration, use regular non visual objects for service objects which you need to pass by reference.