[code] Enabling ta to edit large files

From: Nicholas Ochiel <nochiel.att.gmail.com>
Date: Fri, 8 Jun 2018 16:56:40 +0300

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:
- http://blog.atom.io/2017/10/12/atoms-new-buffer-implementation.html
- https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation
- 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?

Nicholas Ochiel
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Fri 08 Jun 2018 - 09:56:40 EDT

This archive was generated by hypermail 2.2.0 : Sat 09 Jun 2018 - 06:47:59 EDT