#3386 performance of [concat] and empty lists

[miguel sofer]

As noted in bugs 1143805 and 1178805, [concat]'s
performance may suffer when one of it's arguments is an
empty list.

Specifically, as empty lists may have non-list internal
representations, they appear as empty strings.
Currently this can force an unnecessary round trip over
the string rep when all arguments are pure lists but
some of them are empty.

[miguel sofer]

Logged In: YES
user_id=148712
Originator: YES

Fixed by optimizing for any Tcl_Obj that are either empty lists or objs with an empty string rep, independently of their internal rep.
Leaving open as a remainder: is it possibly worth optimising for dicts too?

[Donal K. Fellows]

Logged In: YES
user_id=79902
Originator: NO

Since I don't really recommend concatenating dicts at all, what you do about them is not a big issue to me.

[miguel sofer]

Logged In: YES
user_id=148712
Originator: YES

Oops ...this turned Tcl_ConcatObj from reader to hairy monster, see [Bug 2055782]. This is against the documented behaviour. This only happens when concat'ing one or more empty objs with a single list.

Additionally Tcl_ConcatObj() would corrupt its input when: all things to be concat'ed were either empties or canonical lists, and at least 2 were not empty, and the first one was unshared. In that case it would add the new elements in place, hence modifying its input. THIS IS VERY BAD!

Fixed now in 8-5-branch and HEAD.