VIM отключает автоматическую новую строку в конце файла
1) основано на том факте, что для вызова функции DLL всегда используется дополнительный косвенный переход. Сегодня это обычно незначительно. Внутри DLL есть некоторые дополнительные затраты на процессоры i386, потому что они не могут генерировать независимый от позиции код. На amd64 переходы могут быть относительно счетчика программы, так что это огромное улучшение.
2) Это правильно. Оптимизация, основанная на профилировании, обычно дает 10-15% производительности. Теперь, когда скорость процессора достигла своего предела, возможно, стоит сделать это.
Я бы добавил: (3) компоновщик может упорядочить функции в более эффективную кэш-группировку, чтобы минимизировать дорогостоящие пропуски уровня кеша. Это также может особенно повлиять на время запуска приложений (основываясь на результатах, которые я видел с компилятором Sun C ++)
И не забывайте, что с DLL не может быть выполнено удаление мертвого кода. В зависимости от языка код DLL может быть неоптимальным. Виртуальные функции всегда виртуальны, потому что компилятор не знает, перезаписывает ли его клиент.
По этим причинам, если нет реальной необходимости в DLL, просто используйте статическую компиляцию.
РЕДАКТИРОВАТЬ (чтобы ответить на комментарий, подчеркивание пользователя)
Вот хороший ресурс о проблеме кода, независимого от позиции http://eli.thegreenplace.net/2011/11/03/ position-independent-code-pic-in-shared-library /
Как объяснено, x86 не имеет их AFAIK ни для чего другого, кроме 15-битных диапазонов перехода, а не для безусловных переходов и вызовов. Вот почему функции (от генераторов), имеющие более 32K, всегда были проблемой и нуждались во встроенных батутах.
Но в популярных x86 ОС, таких как Linux, вам не нужно заботиться о том, чтобы файл SO / DLL не генерировался с помощью переключателя gcc -fpic (который обеспечивает использование таблиц косвенных переходов). Потому что, если вы этого не сделаете, код будет просто исправлен, как обычный компоновщик переместит его. Но при этом он делает сегмент кода недоступным для совместного использования, и ему потребуется полное отображение кода с диска в память и касание всего этого, прежде чем его можно будет использовать (очистка большей части кэшей, обращение к TLB) и т. Д. Было время когда это считалось медленным ... слишком медленным.
Так что вы больше не получите никакой пользы.
Я не помню, какие ОС (Solaris или FreeBSD) доставляли мне проблемы с моей системой сборки Unix, потому что я просто не делал этого и задавался вопросом, почему она вылетала, пока я не применил -fPIC к gcc.
5 ответов
Я не пробовал эту опцию, но в справочной системе vim представлена следующая информация (например, help eol):
'endofline' 'eol' boolean (default on)
local to buffer
{not in Vi}
When writing a file and this option is off and the 'binary' option
is on, no <EOL> will be written for the last line in the file. This
option is automatically set when starting to edit a new file, unless
the file does not have an <EOL> for the last line in the file, in
which case it is reset.
Обычно вам не нужно устанавливать или сбросить эту опцию. Когда 'двоичный' off значение не используется при записи файл. Когда 'двоичный' включен, это раньше помнил присутствие для последней строки в файле, чтобы при записи файла ситуация из исходного файла может быть сохраненным. Но вы можете изменить это, если вы хотите.
Вас также может заинтересовать ответ на предыдущий вопрос: « Почему файлы должны заканчиваться новой строкой ».
Может, вы посмотрите, почему они жалуются. Если в php-файле после окончания?> Есть новая строка, php выведет ее как часть страницы. Это не проблема, если вы не попытаетесь отправить заголовки после включения файла.
Однако?> В конце файла php не является обязательным. Нет конца?>, Нет проблем с новой строкой в конце файла.
Можно ли использовать специальную команду для сохранения этих файлов?
Если вы выполните: set binary,: w и: set nobinary, файл будет записан без новой строки, если Начинать было не с чего.
Эта последовательность команд, конечно же, могла быть помещена в пользовательскую команду или отображение.
Добавьте следующую команду в ваш .vimrc, чтобы отключить параметр конца строки:
autocmd FileType php setlocal noeol binary fileformat=dos
Однако сам PHP будет игнорировать этот последний конец строки - он не должно быть проблемой. Я почти уверен, что в вашем случае есть что-то еще, добавляющее последний символ новой строки, или, возможно, есть смешение с типами окончания строки windows / unix ( \ n или \ r \ n и т. Д.).
Обновление:
Альтернативным решением может быть просто добавить эту строку в ваш .vimrc:
set fileformats+=dos
Хорошо, вы работаете в Windows все усложняет;)
Поскольку параметр 'binary' сбрасывает параметр 'fileformat' (а запись с установленным параметром 'binary' всегда записывает с окончанием строки unix), давайте возьмем большой молоток и сделаем это извне!
Как об определении автокоманды (: help autocommand) для события BufWritePost? Эта автокоманда выполняется после каждой записи всего буфера. В этой автокоманде вызывается небольшой внешний инструмент (php, perl или любой другой скрипт), который удаляет последнюю строку новой строки только что записанного файла.
Таким образом, это будет выглядеть примерно так и войдет в ваш файл .vimrc:
autocmd! "Remove all autocmds (for current group), see below"
autocmd BufWritePost *.php !your-script <afile>
Обязательно прочтите всю документацию vim об автокомандах, если вы впервые имеете дело с автокомандами. Есть некоторые предостережения, например, рекомендуется удалить все autocmd из вашего .vimrc на случай, если ваш .vimrc может быть получен несколько раз.