IE中的可调整性能
我在使用jeditable的IE中看到非常差的页面设置时间。
该页面有一个表格，其中每行有13个span元素，jeditable应用于这些元素，如下所示：
$(document).ready(function() { $('#entry_pl span.ples').editable('my_xhr.php', { placeholder: 'unset', indicator: '
', data: function(value, settings) { return $('').html(value).text(); } }); }); function很棒 – 一切正常。 但是在IE 6 … 8中，上面的代码每个表行需要半秒钟。 因此，对于10行表，页面设置延迟已经很糟糕了。 用户不会对此感到满意。 WebKit和Firefox中的设置延迟可以忽略不计。
有什么想法或建议吗？
我还没有开始审查或分析可编辑的可执行代码。
而且我想可能只在点击元素时调用元素上的.jeditable（）而不是$（document）.ready（）中的所有元素。
Che，我做了一堆测试和分析，以确定哪些代码占用了时间。 jeditable不是唯一的罪魁祸首，但它占据了最大的份额。 我真的很好奇为什么它为你而不是我快速工作。
一种可能性是我在iMac上的VirtualBox VM中在XP上运行IE。 这不是一个快速的设置，但这很好，因为我的一些客户使用旧的，慢的或超载的计算机，我希望应用程序也适合他们。
无论如何，好消息是我找到了一个简单而有效的解决方案，我可以分享。 我摆脱了$（document）.ready（）中的所有.jeditable（）调用。 我给表中的每个可编辑span元素赋予了如下属性：onclick =“ed（this）”。 你可以想象ed（）看起来像什么：
function ed(elem) { $elem = $(elem); ... $elem .removeAttr('onclick') .editable('action_script.php', { ... } }) .click(); }
现在让我们考虑一下。 无论如何，这可以说是正确的方法，因为在页面重新加载之前，几乎所有表中的可编辑元素都不会被编辑（至少在我的情况下是这样）。 将所有这些元素设置为可编辑以防万一它们被点击是相对于仅在单击它们时使它们可编辑而言效率相当低。
刚刚解决了这个。 如果你可以没有它，请注释掉以下四行代码，它会大大加快我的速度。
var savedwidth = $(self).width(); var savedheight = $(self).height(); ... settings.width = savedwidth; settings.height = savedheight;
我正在为一个页面开发类似的function，你的post给了我一个惊吓，因为我已经几天没有在IE浏览器中看到它。
不过我现在只是在IE 6 – 8中看到它，我没有遇到与你相同的糟糕设置性能。 我有13行，每行有6个可编辑的字段。 加载后的页面加载和性能都很快。 我创建了一个包含多个可编辑元素的类似页面，这些元素现在已经存在了六个月，并且没有报告性能下降。 现在在IE中查看它有130个可编辑元素，加载和执行就像我当前的页面一样快捷。
在这两种情况下，我都使用jeditable附加了一个比使用单个类作为选择器更加草率的方法。
所以我不相信你的问题是可以接受的。
也许是的。 当我得到我想要的当前页面的行为时，我将尝试将jeditable绑定到更高级别的容器并使用事件冒泡，如本文第7点中所讨论的那样增加jquery性能的方法 。 也许这会对你有所帮助。
祝你好运。