Java对象分配开销 [英] Java object allocation overhead

问题描述

我在Java中编写一个不可变的DOM树，以简化多个线程的访问。*

I am writing an immutable DOM tree in Java, to simplify access from multiple threads.*

但是，它需要尽可能快地支持插入和更新。因为它是不可变的，如果我改变树的第N级的节点，我需要分配至少N个新节点，以返回新的树。

However, it does need to support inserts and updates as fast as possible. And since it is immutable, if I make a change to a node on the N'th level of the tree, I need to allocate at least N new nodes in order to return the new tree.

我的问题是，是否会更快地预分配节点，而不是每次修改树时创建新的节点？这将是相当容易做 - 保持几百个未使用的节点的池，并拉出一个池，而不是创建一个修改操作所需的一个。当没有其他事情发生时，我可以补充节点池。 （如果不明显，在这个应用程序中的执行时间会比堆空间多得多）

My question is, would it be dramatically faster to pre-allocate nodes rather than create new ones every time the tree is modified? It would be fairly easy to do - keep a pool of several hundred unused nodes, and pull one out of the pool rather than create one whenever it was required for a modify operation. I can replenish the node pool when there's nothing else going on. (in case it isn't obvious, execution time is going to be much more at a premium in this application than heap space is)

这是否值得？有关加速的其他提示吗？

Is it worthwhile to do this? Any other tips on speeding it up?

或者，有人知道一个不可变的DOM库已经？我搜索过，但找不到任何东西。

Alternatively, does anyone know if an immutable DOM library already? I searched, but couldn't find anything.

*注意：对于那些不熟悉不变性概念的人来说，它基本上意味着在任何操作到一个更改它的对象，该方法返回一个对象的副本，该对象的位置有更改，而不是更改的对象。因此，如果另一个线程仍在读取对象，它将继续愉快地对旧版本进行操作，不知道已经进行了更改，而不是可怕地崩溃。请参阅 http://www.javapractices.com/topic/TopicAction.do?Id = 29

*Note: For those of you who aren't familiar with the concept of immutability, it basically means that on any operation to an object that changes it, the method returns a copy of the object with the changes in place, rather than the changed object. Thus, if another thread is still reading the object it will continue to happily operate on the "old" version, unaware that changes have been made, rather than crashing horribly. See http://www.javapractices.com/topic/TopicAction.do?Id=29

推荐答案

现在，对象创建很快，对象池的概念是一种过时（至少在一般情况下;连接池当然仍然有效）。

These days, object creation is pretty dang fast, and the concept of object pooling is kind of obsolete (at least in general; connection pooling is of course still valid).

避免过早优化。创建你的节点，当你需要他们在做你的副本，然后看看是否变得过于缓慢。如果是这样，那么看看一些技术，以加快速度。但除非你已经知道你所拥有的速度还不够快，否则我不会介绍你需要的所有复杂性，才能实现流动。

Avoid premature optimization. Create your nodes when you need them when doing your copies, and then see if that becomes prohibitively slow. If so, then look into some techniques to speed it up. But unless you already know that what you've got isn't fast enough, I wouldn't go introducing all the complexity you're going to need to get pooling going.

这篇关于Java对象分配开销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！