Лучше всего приблизьтесь к содержанию больших доступных для редактирования документов в памяти

О, я вижу, что frodo2975 поймал, что вы переходили в вычисленное значение, а не в свои данные. Я этого не заметил. Это работает так, как вы намереваетесь:

new Vue({
  el: '#app',
  data: {
    flights: [
      7, 6, 5, 4, 3, 2, 1, 0
    ]
  },
  computed: {
    chunkedFlights() {
      return _.chunk(this.flights, 4);
    }
  },
  mounted() {
    setTimeout(() => {
      this.flights.unshift(8);
    }, 2000);
  }
});
#app {
  display: grid;
  grid-gap: 2rem;
  background-color: black;
  padding: 0.6rem;
}

.page {
  background-color: #ffe;
  padding: 0.6rem;
  grid-gap: 0.2rem;
  display: grid;
}

.row {
  background-color: blue;
  color: white;
  padding: 0.6rem;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.11/lodash.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js"></script>
<div id="app">
  <div v-for="chunk in chunkedFlights" class="page">
    <div v-for="flight in chunk" class="row">
      {{flight}}
    </div>
  </div>
</div>

5
задан Svante 8 May 2009 в 08:20
поделиться

7 ответов

Я бы предложил разбить файл на блоки. Все блоки имеют одинаковую длину при загрузке, но длина каждого блока может измениться, если пользователь редактирует эти блоки. Это позволяет избежать перемещения 100 мегабайт данных, если пользователь вставляет один байт впереди.

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

Размер файла: 100 МБ
Размер блока: 16 КБ
Блоки: 6400

Поиск смещения с использованием бинарного поиска (наихудший case): 13 шагов
Модификация блока (наихудший случай): копирование 16384 байтовых данных и обновление 6400 смещений блока
Модификация блока (средний регистр): копировать 8192-байтовые данные и обновлять 3200 смещений блоков.

Размер блока 16 КБ - случайный пример. Вы можете сбалансировать стоимость операций, выбрав размер блока, возможно, на основе размера файла и вероятности операций. , Выполнение некоторой простой математики даст оптимальный размер блока.

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

Наконец, реализация не будет слишком сложной. Вы можете просто использовать класс StringBuilder для представления блока. Но это решение не будет работать хорошо для очень длинных линий с длинами, сопоставимыми с размером блока или больше, потому что вам придется загружать много блоков и отображать только небольшие части, а остальное будет слева или справа от окна. Я предполагаю, что в этом случае вам придется использовать двухмерную модель разбиения.

4
ответ дан 13 December 2019 в 19:35
поделиться

Я бы использовал b-дерево или пропустил список строк или блоков большего размера, если вы не собираетесь много редактировать.

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

Вы можете перемещать строки внутри узла без особых усилий.

Общая длина текст в каждом узле сохраняется в узле, и изменения распространяются вплоть до родительских узлов.

Каждая строка представлена ​​массивом данных и начальным индексом, длиной и емкостью. Разрыв строки / возврат каретки не помещаются в массив данных. Обычные операции, такие как разрыв строки, требуют только изменения ссылок на массив; для редактирования строк требуется копия, если емкость превышена. Аналогичная структура может временно использоваться для каждой строки при редактировании этой строки, поэтому вы не выполняете копирование при каждом нажатии клавиши.

1
ответ дан 13 December 2019 в 19:35
поделиться
1
ответ дан 13 December 2019 в 19:35
поделиться

Хорошая математика, плохая Некоторое время назад Мат написал отличную статью о канатах и ​​буфере разрыва , в которой подробно описываются стандартные методы представления текстовых файлов в текстовом редакторе и даже сравнивается их для простоты реализации и производительности. В двух словах: буфер пробела - большой массив символов с пустым разделом сразу после текущей позиции курсора - это ваша самая простая и лучшая ставка.

4
ответ дан 13 December 2019 в 19:35
поделиться

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

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

Я согласен с точкой зрения Криса, хотя, вероятно, лучше сначала сделать что-то простое, и затем посмотрите, действительно ли он медленный ..

0
ответ дан 13 December 2019 в 19:35
поделиться

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

-1
ответ дан 13 December 2019 в 19:35
поделиться

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

FWIW делает вывод, что сдельные столы в целом немного лучше; хотя net.wisdom, похоже, предпочитает буферные промежутки.

2
ответ дан 13 December 2019 в 19:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: