Re: [code] Enabling ta to edit large files

From: Mitchell <>
Date: Sat, 9 Jun 2018 17:48:44 -0400 (EDT)

Hi Nicholas,

[Sorry for the top-post]

Thanks for your thoughtful e-mail. It deserves a thoughtful reply, but I do not have time to do so this weekend. I will answer early next week when I can.


On Fri, 8 Jun 2018, Nicholas Ochiel wrote:

> I attempted to open a 40MB log file and a compiled react app (one
> large js file) and noticed that ta couldn't open/edit these files in a
> reasonable amount of time and without thrashing the cpu the whole time
> the buffer remained open. I notice the "large file" issue has been
> mentioned before but a more detailed technical breakdown of why this
> happens has never been provided as far as I can tell.
> Recently, vscode and atom both fixed their problems in this regard by
> implementing piece-table styled data structures for buffers:
> -
> -
> - vis (C/Lua) also uses a "piece chain"
> and opens large files instantly.
> I'd like to ask:
> - Please could a more technical description be of the ta/scintilla
> buffer data structure and its performance characteristics be provided
> so that the problem can be understood by plebeians such as myself?
> - What is the best solution to enable ta to perform as well as the
> above mentioned editors? Is there a reason why it shouldn't?
> - If a solution has already been proposed/considered, would anyone be
> willing to provide mentorship for me to implement the solution? If
> one hasn't been discussed, please could I be pointed in the right
> direction on
> 1) where in the codebase of ta/scintilla to focus my attention.
> 2) The best approach to profiling large file performance.
> - Would such a patch be accepted?
> --
> Sincerely,
> Nicholas Ochiel


You are subscribed to
To change subscription settings, send an e-mail to
To unsubscribe, send an e-mail to
Received on Sat 09 Jun 2018 - 17:48:44 EDT

This archive was generated by hypermail 2.2.0 : Sun 10 Jun 2018 - 06:39:30 EDT