Another thought - I just remembered that there's a similarly odd behavior when doing a Find through a relationship if the local key field is a Global - the find gives unexpected behaviors, but if the local key field is a Stored or Unstored calc, it works as expected.
There's definitely something odd about using a Global field on one end of a relationship. See Find through global fields giving odd results - #5 by xochi
Just "GLOBAL" creates the observed performance hit; the calculation aspect doesn't matter. (Globals in relationships are typically a temporal UI filter function. Persistent field content using a global - as you have found - is something to be avoided)
A non-global calculation resulting in a constant, is a stored field on every record. As the context is within the scope of a field in a record, an auto-enter also provides the same benefit without the performance hit.
Right - typically I would use stored indexed calculation fields on both sides of a relationship, but in very large tables (millions of records) there's a significant increase in file size when using stored calcs, which is what led me to look at unstored calcs.
At some point I thought "An unstored calc field with the same value for every record is functionally identically to a Global calculation field" and started using Globals instead. This led to the fun discovery discussed here.
Thank you for all this. Oddball question, is there a way I can search for this? I'm thinking maybe looking at the Database Design and doing a find for global calculations and seeing how they're used or something? IDK... seems tedious, but maybe helpful. Could explain some simple issues... or maybe just ignore and hope Claris gets the bug report and it goes away?
Good question - I can't think of an automated way to do this. In my database, I use a specific naming scheme for fields, so it was fairly easy to find them.
The naming system I use:
kFoobar : ("K" for "Constant" 
) : a fixed value, such as the string "Foobar" (or specific number, or date...)
kgFoobar : a global fixed value (these were the ones causing me trouble)
cFoobar : a calculated field
gFoobar: a regular field with global storage
Since it's easy in the UI to see whether the field is Indexed, and what Type it is (number, date, text) I don't bother including that in the field naming scheme:
The DDR is your friend. The default HTML version is freely supported, and the XML version plugs into things like FMPerception which can find for all this easily.
From a naming convention standpoint.
All $$globals show up in the data viewer
Personal Preference on field level globals:
IF in a data table, the names all start with "zg_" so they sort to the end of the alphabetical lists that show up all over FM's dev environment. "zgm_" for match field "zgk_" for constants. (and a bunch of other z++ type names, "za_" for auto-enters, "zc_" for calculated fields, "zs_" for summary, etc.
If a global field is NOT being used for a matching relationship purpose, it goes into the GLOBALS table and starts with the "g_" so not cluttering data tables for no purpose.
There are also a ton of developer commands that can be used to inspect data, fields, layouts, etc. I wrote on that I use on every layout, that lets me see all the FQFN (Fully Qualified Field names - among other things, like named objects TO names on a given layout, etc. ), to make sure that all fields on a layout are part of the same TOG (supported by naming conventions for TOs)
YMMV
