JavaScript 中不同继承模式的内存/速度基准测试的客观方法?

发布于 2024-08-21 12:42:56 字数 455 浏览 1 评论 0 原文

我经常看到古典继承(通过某些库伪造)、伪古典继承和原型继承之间的争论提到“效率”。然而,我从未见过任何数据支持此类内容。更不用说,当涉及到编码风格而不是算法时,“效率”似乎是一个模棱两可的词。

我想做一些测试来“基准测试”其中一些模式和库。这似乎与我过去见过的大多数算法或显示基准明显不同。你们认为需要测试的重要内容是什么,以及可靠地获得这些数字的最佳方法是什么。

我目前在想什么:

  • 实例化的速度(创建几千个对象的时间 使用每个相同的模式 功能)
  • 内存使用情况(我能想到的唯一方法是查看我的内存 任务管理器。。。有没有更好的 方式)
  • 访问内部属性和方法的速度(迭代 再次计时)
  • 复制速度(迭代计时)
  • 代码行数(同行评审的最佳实践,以下示例带有 计数)

有任何谬误、补充或反对吗?有人在其他地方看到过这个数据吗?

谢谢!

I often see arguments between Classical (faked via some library), Pseudo-Classical and Prototypal Inheritance mention "efficiency." However, I've never seen any data backing any of this kind of stuff up. Not to mention "efficiency" seems like an ambiguous word when it comes to a coding style, rather than an algorithm.

I'd like to do some tests to "benchmark" some of these patterns and libraries. This seems distinctly different than most algorithm or display benchmarks that I've seen in the past. What do you guys think are the important things to test, and what are the best ways to get those numbers reliably.

What I'm thinking currently:

  • Speed of instantiation (Time the creation of a few thousand objects
    using each pattern w/ identical
    functionality)
  • Memory usage (The only way I can think is to look at my memory in the
    task manager... is there a better
    way)
  • Speed of access to internal properties and methods (iteration
    timing again)
  • Speed of copies (iteration timing)
  • Lines of code (Peer reviewed best practice following examples with a
    count)

Any fallacies, additions, or objections? Anyone seen this data elsewhere?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

反话 2024-08-28 12:42:56

此博文链接了一些测试和数字。

另请务必阅读 John Resig 撰写的关于 JavaScript 准确性的这篇文章时间以及它如何影响性能基准。如果您最终没有按照 Residuum 建议使用 JSLitmus,请确保仍然使用自适应测试周期。

尽管我 100% 同意 Darelf 的评论,即您应该测试多个浏览器,但您可以通过按 Shift+Esc 来获取 Chrome 中内存和 CPU 使用情况的详细信息。

There are some tests and numbers linked from this blog post.

Also make sure to read this article by John Resig on the accuracy of JavaScript time and how it affects performance benchmarks. If you don't end up using JSLitmus as Residuum suggested, make sure to still use adaptive test cycles.

Although I agree 100% with darelf's comment that you should test multiple browsers, you can get detail on memory and cpu usage in Chrome by pressing Shift+Esc.

著墨染雨君画夕 2024-08-28 12:42:56

这听起来似乎很明显:您需要记住每个浏览器都会给出不同的结果。它应该是您在测试中创建的任何矩阵的一部分。祝你好运。

This may sound obvious: You'll need to keep in mind that each browser will give different results. It should be part of whatever matrix you create in your testing. Good luck.

挽清梦 2024-08-28 12:42:56

我自己没有使用过它,但是 JSLitmus 看起来是适合这项工作的工具。 这里是使用 JSLitmus 的不同继承方法的基准

如果您测试代码行,并且大小对您的基准测试确实很重要(并且 javascript 文件的大小也很重要),那么您还应该使用 YUI 压缩器

对于内存使用基准,除了查看 Linux 系统中的任务管理器或 top 或 Mac OS X 中的等效项(您也应该测试这些)之外,我没有任何其他想法。

除此之外:祝你好运,请发布你的基准测试检索到的信息。并且不要忘记包含用于再现值的测试方法,以便任何其他感兴趣的程序员可以对您的结果进行同行评审。

I have not used it myself, but JSLitmus looks like the right tool for the job. Here is a benchmark of different inheritance methods using JSLitmus.

If you test for lines of code, and size does really matter to your benchmark (and size of javascript files does matter), then you should also test for the size of minified javascript files using YUI Coompressor.

For the memory usage benchmarks, I do not have any other idea than looking at task manager or top in Linux systems or the equivalent in Mac OS X (and you should test these too).

Apart from that: Good luck and please release the information retrieved by your benchmarks. And don't forget to include the test methods for reproduction of the values, so that any other interested programmers can peer-review your results.

染年凉城似染瑾 2024-08-28 12:42:56

不确定这是否有帮助,但检查 动态跟踪 是否有帮助一些提供数字的好工作。

Not sure whether this will help or not but check dyna trace does some nice job for giving numbers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文