Источник Tcl против пакета Tcl

Question

Допустим, я не хочу указывать полный путь в каждом источнике, когда мне выбрать пакет tcl вместо источника tcl? пакет требует быстрее, чем исходный код?

Я знаю, какие пакеты защищают нас от двойного получения кода, это проблема? Я ищу только функции, поэтому я не возражаю, чтобы функции были получены дважды, но есть ли здесь проблема с производительностью?

Answer 1

Глядя на ваш основной вопрос:

Является ли package require быстрее, чем source?

Их нельзя сравнивать напрямую.

Пакеты представляют собой концепцию более высокого уровня, чем файлы сценариев, которые вы можете source, и часто реализуются с помощью source файла или нескольких. Существует также механизм кеширования, так что, хотя в первый раз вы выполняете package require, он будет определенно значительно медленнее, чем source (поскольку подсистема управления пакетами должна искать пакеты, которые у вас есть, если это не так. узнайте тот, который вы запрашиваете, что на самом деле включает использование source в довольно большом количестве pkgIndex.tcl файлов), последующие вызовы package require, вероятно, будут быстрее, поскольку пакеты не загружаются дважды. После того, как внутренний индекс построен (обычно один раз для каждого интерпретатора), package require из известного, но не загруженного пакета не намного медленнее, чем source непосредственное использование файлов его реализации. За исключением того, что происходит «более высокий уровень»: пакет может вообще не быть реализован с помощью source, а вместо этого может использовать load библиотеки DLL. Или это может быть микс. Это бизнес пакета: все, что вам обычно нужно знать, - это то, что у функции есть имя и версия. Это контрастирует с прямым source, где вам нужно точно знать, где находится код (хорошо, легко, если он находится в известном фиксированном месте или расположен относительно текущего скрипта), а также что этот файл - именно то, что вам нужно. В общем, лучше отделить политику (например, package require foobar 1.2.3) от реализации (например, source -encoding utf8 /usr/local/lib/tcl/packages/foobar_1.2.3/foobar.tcl).

---

Следствием того, что пакеты являются одноразовыми, является то, что они не предназначен для создания экземпляров объектов и объектно-подобных вещей (за исключением тех, которые эффективно документированы синглтонами в API). Вы package require получаете команды построения (которые могут быть классами), а затем используете эти команды для создания экземпляров, которые вам нужны, когда они вам нужны.

Answer 2

Конечно есть проблема с производительностью. Подумайте, что происходит, когда вы запускаете исходную команду:

• Путь, указанный для исходной команды, должен быть открыт.
  Операционная система проверяет путь на наличие разрешений, разрешает символические c ссылки. Это несущественно для вашего конкретного случая. Это может стать серьезным ударом для некоторых приложений, которые снова и снова проверяют пути к файлам (например, веб-серверы).
• Файл читается. Дисковый ввод-вывод. Всегда медленно.
• Файл анализируется и интерпретируется. Синтаксический анализ всегда выполняется медленно.
  Tcl имеет простой набор правил, поэтому его синтаксический анализ, вероятно, выполняется быстрее, чем некоторые.
• Поскольку ваши функции заменены ... Проблема здесь в том, что компилятор байтового кода теперь забывает оптимизации, которые были выполнены, и функция будет работать медленнее, чем обычно, при первом использовании. постарайтесь свести к минимуму использование.

  Мнение: Вы найдете людей, которые просто говорят: «Получите лучшее оборудование». Эти люди - дураки, и это причина того, что большая часть Интернета работает так медленно. Они напрасно тратят ресурсы.