Hi,
TRex can be slow to initialise on a large (individual) TTCN-3 file that contains many elements (~10000 templates) as the outline view is slow to be created.
It may only be possible to fix this with a design change. Currently the outline view is merely given the root node by the analyzer and it builds the tree for the outline by parsing through this looking for suitable elements. As we already go through the tree in TTCN3Analyzer, it may be better to build the list of basic elements to display there and give these directly to the outline to display (it can still work out nested elements itself).
However, it may simply be that the SWT tree is slow to display large numbers of elements.
Thoughts / comments?
Regards, Dominic
Hi Dominic,
Dominic Evans wrote:
Hi,
TRex can be slow to initialise on a large (individual) TTCN-3 file that contains many elements (~10000 templates) as the outline view is slow to be created.
...
However, it may simply be that the SWT tree is slow to display large numbers of elements.
Thoughts / comments?
Unfortunately, I didn't have time to experiment with this. However, i doubt the problem is within the tree traversing. My guess would also be the size of the SWT tree. If this is the case, we could construct the tree somehow lazily, i.e. subnodes are inserted the moment we subtree is expanded and not at the beginning.
On Mon, May 22, 2006 at 06:30:04PM +0200, Benjamin Zeiss wrote:
Dominic Evans wrote:
TRex can be slow to initialise on a large (individual) TTCN-3 file that contains many elements (~10000 templates) as the outline view is slow to be created.
...
However, it may simply be that the SWT tree is slow to display large numbers of elements.
Thoughts / comments?
Unfortunately, I didn't have time to experiment with this. However, i doubt the problem is within the tree traversing. My guess would also be the size of the SWT tree. If this is the case, we could construct the tree somehow lazily, i.e. subnodes are inserted the moment we subtree is expanded and not at the beginning.
I believe this is already the case in eclipse-style content providers. The hasChildren() method indicates when a tree node should have the + marker to indicate the existence of a subtree. The contents of this are not calculated until the + is clicked (invoking the getChildren() method. The problem is that if you have 10,000 templates they are all at the same level of the tree and are all calculated (and displayed) at the same time.
I wonder if it is the getChildren() method being slow (i.e. takes a long time to go through each sibling of the module), which we can do something about, or if it simply the refreshing of the eclipse UI element due to the large contents that is slow, which we cannot do anything about.
Regards, Dominic
trex-devel@informatik.uni-goettingen.de
-
Benjamin Zeiss -
Dominic Evans