Пример деградации производительности из-за использования строгих конструкторов данных

Question

Я читаю о strict data constructors. Связанная статья Вики утверждает, что

«Строгость аннотации могут сделать производительность хуже [потому что] строгость аннотацию заставляет компилятор гарантировать, что поле полностью оценено перед сборкой конструкторы, и если выясняется, что поле была уже оценена, тогда это просто потерянная работа ».

Я не понимаю, почему, если поле уже было оценено, оно было потрачено впустую, так как его значение необходимо в любом случае применить конструктор.

Есть ли пример, иллюстрирующий эту проблему или другие потери эффективности из-за строгости?

Answer 1

Принудительное значение, даже если оно уже оценено, имеет небольшую, но существующую стоимость.

Если у вас есть указатель на то, что может быть или не быть уже оценено (thunk или value), и вы завернете его в ленивый конструктор данных, вы просто скопируете этот адрес на свое место в памяти. Это быстро.

Если у вас есть такой указатель, и вы хотите сохранить его в строгом конструкторе, вы должны сначала его оценить. Это требует проверки младших бит указателя на возможные теги (трюк, указывающий на оценку). Если тега нет, вы фактически переходите к этому указателю на введите thunk. Прежде чем вы это сделаете, вы должны нажать обратный кадр на стек, чтобы поток выполнения возвращался к вам в конце. Затем thunk оценивает себя, помещает результат в регистр и переходит к обратному адресу. Затем вы можете поместить этот результат в память.

Так что, даже если предмет, на который вы указываете, уже оценен, вам все равно нужно выполнить проверку тега. И я верю, что в некоторых случаях оцениваемые вещи не имеют тега (это необязательно), поэтому вся другая работа может все еще произойти - ни за что.