PHP тихо оптимизирует последовательные fseek-команды в одну команду fseek?

Question

Я запускаю Windows   7 - 64-разрядный, с последней версией XAMPP, которая имеет 32-битную версию PHP.

На тестировании http://php.net/manual/en/function.fseek.php#112647 для очень большого файла (больше, чем PHP_MAX_INT 2147483647) Теперь я вполне уверен, что последовательно следующие fseeks суммируются перед казнью на filepointer.

У меня есть два вопроса:

1. Могу ли я разбить это суммируя с разумными средствами (или только с обходным, указанной в приведенной выше ссылке)?

2. Является ли это агрегацией в PHP (как я предполагаю, хотя я не знаю, где на PHP) или в Windows   7?

Ответ себя: Попытка двух обходных путей с несколькими изыскивает не работает на моей системе. Вместо этого они помещают filepointer в разные позиции под PHP_MAX_INT. (32-разрядная версия PHP может только стремиться к PHP_MAX_INT + 192. Чтение оттуда по-прежнему возможно, но я не знаю, как далеко.)

Поэтому вопрос устарел для моего конкретного случая, а 32 -битный PHP может искать только PHP_MAX_INT + 8192, что бы вы ни делали. I оставьте вопрос, потому что два человека проголосовали за него, и может быть заинтересован в общем ответе.

Я подал отчет об ошибке здесь:
https://bugs.php.net/bug.php?id=69213
Результат: С 64-битной PHP сборки он может работать, но я не пробовал.

Answer 1

Это не так. Это на самом деле что-то делает даже тупой. Вот фрагмент из исходного кода PHP:

 switch(whence) { 
      case SEEK_CUR: 
       offset = stream->position + offset; 
       whence = SEEK_SET; 
       break; 
     } 

Это в кишках реализации для РНР fseek. Что здесь происходит: если вы скажете PHP искать текущую позицию, это переводит это в «эквивалентный» поиск с начала файла. Это работает только тогда, когда вычисление смещений не переполняется; если это так, то offset - это целое число со знаком, так что это неопределенное поведение.

И, ладно, это потому, что PHP буферизует потоки внутри, поэтому им нужно сделать . Но это не обязательно должно быть так.

Возможно, вам лучше всего попытаться выполнить свою работу на языке, который фактически выполняет то, что вы ему рассказываете.

Answer 2

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

Я могу ответить на низком уровне. fseek() в php реализуется с использованием php-потоков. Он объявлен в файле ext/standard/file.h и определен в .c. Его реализация вызывает php_stream_seek(), который вызывает в _php_stream_seek() в streams.c.Выполнение этого низкого уровня осуществляется через оболочку простых потоков, и в этом случае вы можете обратиться к zend_seek или zend_fseek, которые, в свою очередь, просто сопоставляются с 32 или 64-битными seek _ seeki64 c вызовами.

Итак ... если произойдет какое-либо агрегирование, это, похоже, должно быть в оптимизации кода операции или даже ниже в операционной системе или аппаратном обеспечении. Жесткие диски реализуют внекорпоративную выборку для уменьшения расстояний для поиска головы, а системы буферизации файловой системы могут уменьшить количество искажений, которые не имеют побочных эффектов. Если вас беспокоит время чтения диска, первое автоматически обрабатывает это. Если вы заинтересованы в том, чтобы, возможно, перебирая память (требуя больших расстояний без необходимости в буфере), вы могли бы рассмотреть другой подход. Смотрите: http://www.cs.iit.edu/~cs561/cs450/disksched/disksched.html для получения дополнительной информации о том, как диски избегают тратить время поиска.

Надеюсь, это поможет.