Corion called it right!

The simplest fix is to modify:

                $ref_gen_data->{'gp'}{'major_version'},
                $ref_gen_data->{'gp'}{'minor_version'},
[download]

to be:

                0 + $ref_gen_data->{'gp'}{'major_version'},
                0 + $ref_gen_data->{'gp'}{'minor_version'},
[download]

That change will immediately reduce the runtime (on my system) from 27 minutes to 2 seconds.

The source of the problem is that those two elements of the hash are referenced in -textvariable' clauses in Entry() elements within your GUI. This causes Tk to apply tie magic to both variables, which effectively means that every (even read) reference to these variables becomes a chain of function calls to resolve and apply the magic. As the "holder" of the magic is running on a different thread, it also involves multiple context switches. And hence, r-e-a-l-l-y s-l-o-w.

The surprising thing here is that the attached magic survives the transmission of the values of the hash elements between threads via a Thread::Queue. This appears to be by (re)design, when share magic was modified to allow the sharing of (only specially written) objects between threads.

The reason that adding 0 to the values prior to enqueuing them works, is because it forces the value into the IV slot rather than the PV slot. And it appears the magic is only applied to the PV slot.