IE中的jeditable性能

Question

我看到在IE中使用jeditable的页面设置时间非常慢。

该页面有一个表，其中每一行都有13个span元素，jeditable应用如下：

$(document).ready(function() { 
    $('#entry_pl span.ples').editable('my_xhr.php', {
            placeholder: '<span class="placeholder">unset</span>',
            indicator: '<img src="indicator.gif" class="indi">',
            data: function(value, settings) {
                return  $('<span />').html(value).text();
            }
        });
});

功能很棒--一切都能正常工作。但在IE6...8中，上面的代码每表行需要半秒以上。因此，对于一个10行的表来说，页面设置延迟已经很可怕了。用户不会对此感到满意。在WebKit和火狐中，设置延迟可以忽略不计。

有什么想法或建议吗？

为了提高性能，我还没有开始审查或分析jeditable代码。

我在考虑也许只在一个元素被单击时调用.jeditable()，而不是在$(document).ready()中的所有元素上调用。

Answer 1

切，我做了一堆测试和分析，以确定哪段代码占用了我的时间。jeditable并不是唯一的罪魁祸首，但它占据了最大份额。我真的很好奇为什么它对你很有效，而不是对我。

一种可能是，我在iMac上的VirtualBox VM中运行IE。这不是一个快速的设置，但这很好，因为我的一些客户使用的是旧的、慢的或过载的计算机，我希望应用程序也能很好地为他们工作。

无论如何，好消息是我找到了一个简单而有效的解决方案，我可以分享。我去掉了$(document).ready()中的所有.jeditable()调用。我为表中的每个可编辑的span元素赋予了一个类似如下的属性: onclick="ed(this)“。您可以想象ed()是什么样子的：

function ed(elem) {
    $elem = $(elem);
    ...
    $elem
        .removeAttr('onclick')
        .editable('action_script.php', {
            ...
            }
        })
        .click();
}

现在让我们考虑一下这个问题。无论如何，这可以说是正确的方法，因为在页面重新加载之前，表中几乎所有的可编辑元素都不会被编辑(至少在我的例子中是这样)。将所有这些元素设置为可编辑，以防它们可能被单击，与仅当它们被单击时才将它们设置为可编辑相比，效率相当低。

Answer 2

刚刚解决了这个问题。如果你可以没有它，注释掉下面四行代码，它会大大加快我的速度。

       var savedwidth  = $(self).width();
       var savedheight = $(self).height();
       ...
       settings.width  = savedwidth;
       settings.height = savedheight;

Answer 3

我目前正在为一个页面开发类似的功能，你的帖子给了我一个地狱般的恐惧，因为我已经有几天没有在IE中看到它了。

然而，我现在已经在IE6-8中看到了它，我不会像你一样体验到糟糕的设置性能。我有13行，每行有6个可编辑字段。页面加载和加载后的性能都很快。我创建了一个具有多个可编辑元素的类似页面，该页面已经运行了六个月，没有性能缓慢的报告。现在在IE中看看它，它有130个可编辑的元素，加载和执行起来和我当前的页面一样快。

在这两种情况下，我都以一种比使用单个类作为选择器的方法更草率的方式附加了jeditable。

所以我不相信你的问题是可以抛弃的。

不过，也许就是这样。当我在当前页面上获得我想要的行为时，我将尝试将jeditable绑定到更高级别的容器，并使用事件冒泡，如本文11 ways to increase your jquery performance的第7点所述。也许这会对你有帮助。

祝你好运。