从列表中删除/隐藏大量元素的最快方法

时间:2012-12-19 02:06:08

标签: javascript

我有一个下拉列表,其中包含大约100,000行组成一个列表。

<input id="search" type="text" />
<ul>
    <li>item 1</li>
    <li>item 2</li>
        ...
    <li>item 100,000</li>
</ul>

我有一个充当搜索的文本框,因此当您键入时,它会匹配列表中项目的输入,删除不匹配的内容。这是我写的用于执行列表元素删除的类。

See the fiddle (list has about 2000 items)

// requires jQuery
var Search = (function(){

    var cls = function (name) {
        var self = this;

        self.elem = $('#' + name);
        self.list = $('#' + name).next('ul').children();
        self.elem.bind('keyup', function () { self.change(); }); 
    };

    cls.prototype = {
        change: function () {
            var self = this;
            // gets the closest ul list
            var typed = self.elem.val();

            // only do something if there is something typed
            if (typed !== '') {
                // remove irrelevent items from the list
                self.list.each(function () {
                    var item = $(this).html();
                    if (item.indexOf(typed) === -1)  {
                        $(this).addClass('zero');
                        // tried using a class with visibility hidden
                    } else {
                        $(this).removeClass('zero');
                    }
                });
            } else {
                // check what list items are 'hidden' and unhide them
                self.list.each(function () {
                    if ($(this).hasClass('zero')) {
                        $(this).removeClass('zero');
                    }
                });
            }
        }
    };
    return cls;
}());

我只是添加一个高度为0的类,没有边距,填充等,但我也尝试使用visibility:hidden。我也尝试在jQuery中使用detach方法,但速度方面大致相同。

他们的任何JavaScript专家是否可以看到代码的任何问题,或提供一些优化技术?

2 个答案:

答案 0 :(得分:3)

当人们总是只使用小子集时,保持40k行并不是一个现实的解决方案。你可以做的就是缓存它。

  1. 仅保留最常用的。
  2. 使用的越多,它就越多出现在顶部。
  3. 如果它从未使用它将永远不会出现。针对此类情况启动ajax请求。

答案 1 :(得分:3)

这可以“相对较好”(在桌面浏览器中完成),即使有大量项目 - 尽管实际性能会因其他因素而有所不同。

保持用户界面响应的“技巧”是通过setTimeoutsetInterval来处理搜索/过滤,这只是“一次只做很多工作”。我发现,至少在IE7 / 8中,当我在侧边栏小工具中使用时,20ms / 30ms的工作/休息效果很好。 YMMV。

如果完全无法搜索(例如使用缓存从阵列或其他可搜索的结构中即时重新创建n项),那么这可能会付出代价以及 - 运行一些基准! - 并使搜索更简单。

当然,使用服务器端解决方案(例如AJAX),至少对于“粗粒度结果”,根据用例情况也可能更合适。