Working on the fix for use-after-free bug, I noticed that there is performance penalty by creation (and/or deletion) of interp.

Here is the comparison 9.0 (-) vs 8.6 (+):

  % timerate {interp create i; interp delete i} 5000
- 3574.98 µs/# 1398 # 279.72 #/sec 4997.816 net-ms
+ 1756.77 µs/# 2846 # 569.23 #/sec 4999.777 net-ms

  # still worse it looks with safe interp:
  % timerate {interp create -safe i; interp delete i} 5000
- 1228.34 µs/# 4070 # 814.11 #/sec 4999.341 net-ms
+ 460.025 µs/# 10869 # 2173.8 #/sec 5000.009 net-ms

However 8.7 seems to have the same "bottleneck" (although a bit faster).

I had a 9.x-based branch with lazy load of clock, OO and few other stuff... it is significantly faster, but anyway a bit slower than 8.6...

Since I don't have time right now to profile it, but it looks significant, I let it here as a ticket.

Closing this while cleaning up bug reports as performance is now 2x even 8.6. Further improvements are always possible but that is a generic goal not specific to this ticket.

Current trunk:

```
% timerate {interp create i; interp delete i} 5000
1066.21 µs/# 4689 # 937.90 #/sec 4999.442 net-ms
```

9.0.2:

```
%  timerate {interp create i; interp delete i} 5000
4725.25 µs/# 1057 # 211.63 #/sec 4994.590 net-ms
```

8.6:

```
% timerate {interp create i; interp delete i} 5000
2153.04 µs/# 2322 # 464.46 #/sec 4999.364 net-ms
```

TclOO was one of the contributors to this. I've cut about 25% of the time off of the whole interp create/delete cycle from making the initialisation script contain less (by moving pieces into C). There might be further places that can be improved.

For one proposed improvement see [5773c78e86](https://core.tcl-lang.org/tcl/tktview/5773c78e86)

Branch for lazy load of clock ([04742d889c]) illustrates the possible win of changeover for single namespace/ensemble to on-demand load, where the performance win is ca. 200 µs/#. The switch of further subsystems to lazy loading may reduce interpreter creation time to ca. 1000 µs/# what would be almost double as fast than current 8.6 (and tipple as fast than current 9.x).

However, as already said, it'd expect at least TIP#689 (namespace unknown), and some of the subsystems also further improvements, that may help to load namespace on demand by any access (e. g. on variable or on namespace resolution).

Great ! And the source code change is documented, I appreciate !
Thanks for all,
Harald

[4318f0e945ce26ee] fixes a part of it (improves interpreter creation speed also in case if there is no zipfs tcl-library), so eliminating the costs of ca. 1200 µs/#.

I'd let this ticket open till I found remaining extra costs and/or provide my lazy-loading stuff for clock/etc as ready solution for 9.x (however I guess we'd at least resume TIP#689 and further namespace unknown improvements).