как быстро часть Python

Я тоже не проводил никаких измерений, но поскольку похоже, что вы уже применяете подход C к проблеме в Python, вы можете взглянуть на Python встроенная библиотека mmap :

Отображенные в память файловые объекты ведут себя как строки и как файловые объекты. Однако, в отличие от обычных строковых объектов, они изменяемы. Вы можете использовать объекты mmap в большинстве мест, где ожидаются строки; например, вы можете использовать модуль re для поиска в файле с отображением в память. Поскольку они изменяемы, вы можете изменить один символ, выполнив obj [index] = 'a', или изменить подстроку, присвоив срезу: obj [i1: i2] = '...'. Вы также можете читать и записывать данные, начиная с текущей позиции файла, и искать () через файл в разные позиции.

I ' Я не уверен, из-за вашего вопроса, если это именно то, что вы ищете. И повторяю, что вам нужно снять некоторые измерения. Библиотека Python timeit проста в использовании, но есть также cProfile или hotshot , хотя hotshot является рискует быть удаленным из стандартной библиотеки, насколько я понимаю.

преждевременная оптимизация - это корень всего зла.

Докажите себе, что вам действительно нужна оптимизация кода, и действуйте.

В комментарии OP упоминает раздувание «в базе данных» - но нет информации о том, о какой базе данных он говорит ; Судя по скудной информации в этом комментарии, может показаться, что фрагменты строки Python не обязательно должны быть задействованы, скорее, «нарезка» будет выполняться механизмом БД при извлечении.

Если это реальная ситуация, я бы рекомендовал общие принципы против хранения избыточной информации в БД - «нормальная форма» (может быть, в слабом смысле выражения ;-), при которой информация сохраняется только один раз, а производная информация пересчитывается (или кэшируется загрузка механизма БД и т. д .; -) должна быть норма, а "денормализация" путем преднамеренного хранения производной информации в значительной степени исключение и только тогда, когда это оправдано конкретными, хорошо измеренными потребностями в производительности поиска.

Если ссылка на «базу данных» была неправильной ;-), или, скорее, использовалась в слабом смысле, как я для "нормальной формы" выше ;-), тогда может применяться другое соображение: поскольку строки Python неизменяемы, было бы естественно не делать срезы путем копирования, а, скорее, чтобы каждый срез повторно использовал часть пространства памяти родительский элемент, из которого он вырезан (так же, как это делается для срезов массивов numpy). Однако в настоящее время это не является частью ядра Python. Однажды я пробовал использовать патч для этой цели, но проблема добавления ссылки на большую строку и, таким образом, сохранения ее в памяти только потому, что на ее крошечную подстроку все еще ссылаются, вырисовывалась большая для универсальной адаптации. Тем не менее, можно было бы создать специальный подкласс строки (и один из unicode) для случая, когда большая «родительская» строка все равно должна оставаться в памяти. В настоящее время buffer выполняет крошечную часть этого, но вы не можете вызывать строковые методы для объекта буфера (без явного копирования его сначала в строковый объект), поэтому он действительно полезен только для вывода и некоторых специальных случаях ... но нет реального концептуального блока против добавления строкового метода (я сомневаюсь, что это будет принято в ядре, но в любом случае его должно быть достаточно легко поддерживать как сторонний модуль ;-).

Ценность такого подхода вряд ли может быть убедительно доказана измерениями, так или иначе - скорость была бы очень похожа на текущий подход неявного копирования; Преимущество будет полностью связано с уменьшением объема памяти, что не столько ускорит какой-либо конкретный код Python, а скорее позволит определенной программе выполняться на машине с немного меньшим объемом оперативной памяти или лучше выполнять многозадачность, когда несколько экземпляров используются одновременно в разных процессах. См. rope , где описан похожий, но более богатый подход, с которым когда-то экспериментировали в контексте C ++ (но обратите внимание, что он не вошел в стандарт; -).

что не сильно ускорит какой-либо конкретный код Python, а скорее позволит определенной программе выполняться на машине с немного меньшим объемом оперативной памяти или лучше выполнять многозадачность, когда несколько экземпляров используются одновременно в отдельных процессах. См. rope , где описан похожий, но более богатый подход, с которым когда-то экспериментировали в контексте C ++ (но обратите внимание, что он не вошел в стандарт; -).

что не сильно ускорит какой-либо конкретный код Python, а скорее позволит определенной программе выполняться на машине с немного меньшим объемом оперативной памяти или лучше выполнять многозадачность, когда несколько экземпляров используются одновременно в отдельных процессах. См. rope , где описан похожий, но более богатый подход, с которым когда-то экспериментировали в контексте C ++ (но обратите внимание, что он не вошел в стандарт; -).

Могут ли срезы быть неэффективными, поскольку они создают копии исходной строки? Это может быть, а может и не быть проблемой. Если это окажется проблемой, невозможно ли просто реализовать «строковое представление»; объект, который имеет ссылку на исходную строку и имеет начальную и конечную точки .. При доступе / итерации он просто читает из исходной строки.