Можно ли (или необходимо) утилизировать объекты textpointer в flowdocument?
Я построил программу, которая загружает Xaml в
RichTextBox
, а затем проходит по тексту предложение за предложением, используя Regex
чтобы найти слова против глоссария.Из
Regex Matches
, Я тогда создаю TextRange
s (от TextPointer
s, определяемые по формуле Match.Index
, отсчитывая от Document.ContentStart
), и я храню их в List<TextRange>
.Затем я выделяю каждый из них
TextRange
в списке с помощью TextRange.ApplyPropertyValue(TextBlock.BackgroundProperty, myHighlightBrush).
Эта процедура должна выполняться для каждого предложения, поэтому каждый раз я очищаю
List
а потом пересчитать TextPointer
на следующий срок.(Этот
TextRange
ы должны быть в работающем List
чтобы получить доступ к тексту этих диапазонов позже).После многих проб и ошибок я получил программу, чтобы сделать именно то, что я хочу, но есть проблема:
Когда я использую его непрерывно в течение более часа или около того, процедура становится все медленнее, и благодаря некоторой отладке мне удалось сузить замедляющую часть до фактического выделения текстовых диапазонов.
Если программа закрывается и снова открывается, и запускается с предыдущей точки, скорость выделения снова приемлема, и предсказуемо через час или около того, она снова начинает становиться невыносимо медленной.
Что я уже пробовал:
Некоторые вещи, которые я пробовал, это:
1) Run.Background подсветка вместо TextBlock, т. е.
TextRange.ApplyPropertyValue(Run.BackgroundProperty, myHighlightBrush);
2) восстановление списка вместо его очистки, т. е.
List<TextRange> ranges = new List<TextRange>();
Но это, похоже, не имеет никакого эффекта с точки зрения прогрессирующего замедления.
Что мне интересно, так это то, что происходит со всеми этими людьми.
TextPointer
ы, которые я создавал на этом пути? Я не могу найти никакого способа избавиться от старых, так что они автоматически удаляются? Если нет, то не могли ли они замедлить ход событий, поскольку, по-видимому, RichTextBox
приходится делать эвристические вычисления для каждого TextPointer
всякий раз, когда в него вносятся изменения. Или, может быть, все эти текстовые указатели просто вызывают утечку памяти?Достаточно ли очистить список, чтобы избавиться от
RichTextBox
из предыдущих TextPointer
s и TextRange
с?Я не могу найти никакой информации в сети о том, что происходит с
TextPointer
s после того, как вы закончите их использовать...
Richard MacCutchan
Когда вы очищаете список, вы сначала очищаете все текстовые указатели и текстовые диапазоны в списке? если они все еще указывают на какие-то данные, то GC не будет их собирать.
mycenean
Когда я очищаю список, я понятия не имею, как "очистить" текстовые указатели/текстовые диапазоны, будет ли это означать просто установить их в ноль?
Richard MacCutchan
Да, это очищает их счетчики ссылок, чтобы их можно было удалить. Кроме того, если данные, на которые они ссылаются, больше не используются, то это пространство памяти также будет освобождено.
mycenean
Хорошо, я попробую установить их равными нулю, прежде чем очистить список, и посмотрю, разрешится ли проблема скорости.
Что касается того, используются ли данные, на которые они ссылаются, все еще или нет, я бы предположил, что они все еще используются, потому что функция TextPointer состоит в том, чтобы ссылаться на местоположение в тексте FlowDocument, и FlowDocument с его текстом все еще существует, конечно.
mycenean
Привет, после попытки еще нескольких запусков (= несколько часов), это, кажется, не решило проблему, к сожалению.
(Я изменил код так, чтобы все текстовые диапазоны в списке были установлены в null перед очисткой списка).
Конечно, я просто предполагаю, что это проблема с текстовыми указателями, и начинаю сомневаться, что это не так, хотя это кажется наиболее вероятной причиной.
Есть идеи, что еще может замедлить выделение в RichTextBox? Люди жаловались на печально известное медленное форматирование в WPF RTB, но при запуске программы оно работает достаточно быстро, и только после более чем часа использования оно начинает становиться вялым.
Richard MacCutchan
К сожалению, это может быть любая из миллиона вещей. Единственный способ выяснить это-добавить отладочные операторы в код, чтобы попытаться выяснить, что происходит. Некоторая форма инструментария также может помочь, если можно найти структуру, которая будет это делать.
mycenean
Конечно, миллион вещей lol, но мне просто интересно, что конкретно может быть известно, чтобы замедлить операцию подсветки (BackgroundProperty) в RTB. (Поскольку никакая другая часть процедуры не замедляется, только выделение).
Но я просто продолжу отладку, ТХ.
Richard MacCutchan
Как я уже сказал ...
Проблема с такими вопросами заключается в том, что на самом деле невозможно сделать разумные предположения, поскольку существует слишком много неизвестных.