Можно ли использовать WebWorkers для расчета частоты слов на очень длинной странице? - PullRequest
Новая
       22

Можно ли использовать WebWorkers для расчета частоты слов на очень длинной странице?

0 голосов
/ 13 апреля 2011

Я пишу инструмент лингвистического анализа на основе браузера (Javascript и jQuery), который извлекает текст из HTML, а затем извлекает языковые единицы, такие как предложения, слова и так далее.

Чтобы импортировать текст, PHP-бэкэнд отслеживает заданный URL-адрес и очищает полученный HTML-код. Затем этот HTML-код вставляется в div#container в интерфейсе, примерно так:

image

Я столкнулся с некоторыми трудностями, когда исходная HTML-страница очень длинная. Чтение и вставка такой страницы в интерфейс DOM, похоже, не вызывает проблем (хотя это занимает некоторое время).

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

Итак, я вижу несколько вариантов:

  1. Измените паук PHP, чтобы он обрезал исходный документ или поделил его на несколько документов
  2. Измените алгоритм частоты слова, чтобы он был менее точным, и сэмплируйте распределение слова, а не записывайте его полностью
  3. Попробуйте этот новый инструмент для Web Worker, чтобы узнать, смогу ли я распределить вычисления по нескольким фоновым процессам.

Мне кажется, что (3) - это просто слово, на которое рассчитаны веб-работники. Я представляю, как разбить содержимое паука на куски, а затем назначить по одному веб-работнику для каждого чанка. Профиль частоты слов каждого фрагмента может быть возвращен из Web Worker, а затем суммирован и представлен на диаграмме.

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

1 Ответ

0 голосов
/ 13 апреля 2011

Веб-работники, безусловно, будут приемлемым вариантом, но компромисс в том, что вы не можете гарантировать кросс-браузерную совместимость.Возможно, стоило бы разбить содержимое на куски и использовать setTimeout, чтобы посмотреть, имеет ли это значение.Это предотвратит блокировку браузера и предотвратит появление любых длительных предупреждений сценария.Николас Закас недавно сделал запись в блоге о подобных вещах: http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/

Метод, который он предлагает: 

function chunk(array, process, context){
  var items = array.concat();   //clone the array
  setTimeout(function(){
    var item = items.shift();
    process.call(context, item);

    if (items.length > 0){
        setTimeout(arguments.callee, 100);
    }
  }, 100);
}

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

Если это не улучшит ситуацию, тода, веб-работники могли бы пойти по этому пути.

...