>>>There is ABSOLUTELY NOTHING to gain performance wise to split function up into procedures.
>>
>>First, as I just said in another comment, through VFP 6, including a Procedure or Function header in a PRG file that contained only a single routine, had a performance penalty of about an order of magnitude. Ted or I (don't remember which) tested it when writing HackFox.
>
>I don't think we should take VFP6 as performance benchmark. So much has changed since then.
>
>>Second, to do a realistic test of what the penalty is today for a procedure file, you'd need to try procedure files of different sizes. I strongly suspect that performance drops as the number of routines increases.
>
>Done that with a large procedure file. No difference. It is just as fast.
>
>>Finally, even if there's no performance penalty, procedure files have other negatives, including making it hard to find stuff at design-time (which includes that they can make Thor's Find Definition fail). For me, the worst is that under some circumstances, changes in a procedure file don't show up when you're testing in the IDE. I've been bitten by that a lot.
>
>That really depends on how you organize things. If you have a large projects with hundreds of functions it does not make any sense to load them in the project manager. It makes sense to put them into a single prg library if they are used within the context of the library purpose. It makes it a lot easier to redistribute and hides away functions that are never used outside of that context. Nowadays I'd load everything into classes, but if I'd have a library that has to do with FTP, containing dozens of functions that are used from one main function within that same procedure file, I just don't want to see that stuff in the project manager.
>
>It conflicts Mikes own argument of cohesion he likes to brag about.
>
>>In my view, procedure files stopped having a purpose when the Project Manager was added in FP2. When it's my call, I will always get rid of them. (I wrote a tool to do it, which is now in Thor.)
>
>I've got two procedure files left with functions for a variety of reasons, but since my project manager aready spans 150 prgs and classlibs, there is no benefit to clutter it up with more stuff.
>
>Anyways, this argument was about performance. It has no benefit to put it into seperate PRGS.

You don't know the first thing about cohesion. If I have a speed.prg which is a wrapper to set up the speed.dll, how is it being in any procedure library affecting cohesion, which only matters at run time and now where the files are stored at design time. I don't even waste my breath on you.