Взгляните на это: http://blog.stackoverflow.com/2009/04/podcast-50/
РЕДАКТИРОВАТЬ: Трудно найти конкретные (подтвержденные) ссылки, однако, этот документ, возможно, дает некоторую информацию относительно этого: http://people.mozilla.org/~dmandelin/tracemonkey-pldi-09.pdf и этот пост в блоге, которыйКажется связанным: http://andreasgal.wordpress.com/2008/08/22/tracing-the-web/
Не может быть связано, так как это исследовательская работа Microsoft от марта 2010 года: http://research.microsoft.com/pubs/121449/techreport2.pdf
Чисто умозрительно с моей стороны, но это кажется (по крайней мере, мне)что существуют две основные формы производительности: на уровне разработчика (IDE) и на уровне компилятора, к которым относится этот объект деревьев трассировки, и, следовательно, «непрерывная оптомизация» во время выполнения, чтобы получить трассировку для горячих точек.Это быстро приводит меня к областям оптомизации, связанным с многоядерными процессами, и к тому, как каким-то образом использовать дерево трассировки (многоядерные среды).Интересная вещь, учитывая теоретические предположения о скорости нестатического типа в сравнении с победителями скорости в статическом типе, используемыми в токе C, и потенциалом производительности, который будет получен.Я вспоминаю дискуссию, которая состоялась у меня с инженером по аппаратным средствам несколько лет назад (1979 г.), когда мы предположили, что, если бы мы могли просто уловить «горячие» пути выполнения, мы могли бы получить огромный выигрыш в производительности, сохранив его как-то «готовым к запуску» на месте -это было задолго до работы в HP в этом отношении (1999?), и, к сожалению, мы не продвинулись дальше стадии обсуждения из-за других обязательств.(Я тут болтаю, я думаю ...:)
ИЛИ, это было просто связано с языком GO?Трудно сказать в некоторых отношениях.