En un comentario, el OP menciona hinchazón "en la base de datos", pero no hay información con respecto a qué base de datos está hablando; a partir de la escasa información en ese comentario, parece que las secciones de cadena Python no son necesariamente lo que está involucrado, más bien, el "corte" sería realizado por el motor DB al momento de la recuperación.
Si esa es la situación real, entonces recomendaría principios generales contra el almacenamiento de información redundante en el DB - una "forma normal" (tal vez en un sentido laxo ;-) por el cual la información se almacena una sola vez y deriva la información se vuelve a calcular (o la carga en caché del motor de DB, etc. ;-) debería ser la norma, y la "desnormalización" almacenando deliberadamente la información derivada como excepción y solo cuando se justifica por necesidades de rendimiento de recuperación específicas y bien medidas.
Si la referencia a "base de datos" era una dirección incorrecta ;-), o más bien usada en un sentido laxo como lo hice para "forma normal" ;-), entonces otra consideración puede aplicarse: dado que las cadenas de Python son inmutables, parecería natural no tener que hacer rebanadas copiando, sino más bien hacer que cada porción de reutilización reutilice parte del espacio de la memoria del elemento principal desde el que se va a cortar (de forma muy similar a las divisiones de matrices numpy). Sin embargo, eso actualmente no es parte del núcleo de Python. Una vez probé un parche para ese propósito, pero el problema de agregar una referencia a la secuencia grande y hacer que permanezca en la memoria solo porque una pequeña subcadena de la misma todavía se hace referencia tenía un gran significado para la adaptación de propósito general. Aún así, sería posible crear una subclase de propósito especial de cadena (y una de Unicode) para el caso en el que la cadena "principal" grande necesita permanecer en la memoria de todos modos. Actualmente, buffer hace un poco de eso, pero no se pueden invocar los métodos de cadena en un objeto buffer (sin copiarlo explícitamente a un objeto de cadena primero), por lo que solo es realmente útil para la salida y algunos casos especiales ... pero hay ningún bloqueo conceptual real contra el método de cadena agregada (dudo que se adopte en el núcleo, pero de todos modos debería ser decentemente fácil de mantener como un módulo de terceros ;-).
El valor de tal enfoque difícilmente puede ser probado sólidamente por medición, de una forma u otra - la velocidad sería muy similar a la aproximación actual de copia implícita; la ventaja vendría en términos de reducir la huella de memoria, lo que no haría que un código de Python determinado fuera más rápido, sino que permitiría que cierto programa se ejecutara en una máquina con un poco menos de RAM, o multi-tarea mejor cuando varias instancias se están utilizando al mismo tiempo en procesos separados. Ver rope para un enfoque similar pero más rico una vez experimentado en el contexto de C++ (pero tenga en cuenta que no entró en el estándar ;-).
¿Por qué no probarlo? Escribe una prueba simple. –
Estoy de acuerdo y voté por balpha, pero siempre me pregunté qué tan rápido era la porción de Python. Lo uso todo el tiempo tan fácilmente como una simple asignación, pero estoy seguro de que es mucho más lento que eso. –
-1: no hice ningún experimento de sincronización. –