Argh, union types again. The problem is implementation interplay between UnionTemplate.xtend and its superclass ClassTemplate.xtend around initialization of _value field.
In normal classes this field is final, as it really holds the value. This is not the case for unions, as the value is actually held by one of the constituent fields.
Unfortunately ClassTemplate's requirement to have _value initialized is forcing UnionTemplate to eagerly encode it – which is done in the beautiful bottom part of UnionTemplate#unionConstructors().
The interplay has also further bad effects, as union classes take _value into account in their toString(), hashCode() and equals() methods – and they should not, as this information is already included via the constituent types.
To fix this, unions' _value field must not be final, but rather default to null. It should be initialized on first access via getValue() by looking for the first non-null constituent and convering it to char[]. This means the conversion will be done lazily, fixing the performance issue observed. I am not sure how to do this cleanly.
Also hashCode()/equals()/toString() must not touch the _value in any way, as that would either force its instantiation (shifting the performance problem) or lead to inconsistent results. This can be achieved by not adding "value" via GeneratedTOBuilder.add
{Equals,Hash,ToString}Property() if the target is an union.
Patch to remove _value from hashCode/equals/toString: https://git.opendaylight.org/gerrit/39554.
The patch above should address all concerns.
This is a major performance regression, Be-3 should not ship without a fix.
Apart from checking the generated code, I did some profiling, and while getIpAddressFromInetAddress() still shows up in sampled output with the previously measured ~2 seconds, getIpAddressBinaryFromInetAddress() is completely missing from repeated sampled profiling sessions, which is what I was looking for 
Thanks!