Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Advanced TTCN-3 usage(The secret life of imports)
Advanced TTCN-3 usage [message #1737643] Mon, 11 July 2016 14:29 Go to next message
Kristof Szabados is currently offline Kristof SzabadosFriend
Messages: 29
Registered: July 2015
Junior Member
We have just published a paper on the Visualization of TTCN-3 System Architecture as done in Titanium.

For this reason lets spend a little time with the secret life of import statements:
- How careless usage can slow down the build of tests without anyone noticing.
- How careless usage can increase maintenance costs, and make a test system hard to work with ... without anyone understanding the reason why.

1) Parallel build can be slowed down by unused imports

Titan is compiling TTCN-3 and ASN.1 codes into C++.
As such the import statements found in both language are compiled to "#include" statements.
This way definitions in the compiled version of one module can use the definitions from the compiled version of an other module.
This should not have any side effect whatsoever on the test system itself.

Actually, they can have.
When there is a "#include" (or any other dependency) relation between 2 files, most of the compilers are forced to compile them in order, to forego build problems.
Practically disabling parallel building of the dependent files.

For example if module A imports module B, most compilers will first compile the code generated from module B and only after finishing it, compile the code generated from module A.
So the build time becomes: build_time(module B) + build_time(module A).
While is there is no dependency between them it would be: max(build_time(module B), build_time(module A)).

In many cases we were able to reduce the build time of test suites by 3-10%, just by removing unused imports.
That is: with a little work, we could speed up every upcoming build, without changing any externally perceivable property of the test system.

2) Maintenance and architecture planning cost can be increased by unused imports

Unused imports also lower the efficiency of developers/testers, making their life much harder then needed, and development more costly.

- When a new developer enters the team and wishes to learn how the code is structured, she will most probably try to map the dependency of functionalities in the code. The more unused imports there are, the more unnecessary stuff she will waste her time learning.
- When a code is modified it is wise to check all other source codes using it, to see if they will still work as intended ... each unused import adding one unnecessary module to check.
- When a code is changed, the build system has to rebuild it and all modules which might recursively reach it ... each unused import adding large amounts of unnecessary work for the build system .. reducing the feedback time for the developers doing the change
- When a new function needs to be implemented a clear/clutter free architecture can make it much easier to find where it needs to be in the code. Unused imports can create "imaginary connections" between pieces of the code, that mask the true architecture of the product.

In the worst case unused imports can form circular importations.
They might seem to be a good short cut, compared to designing proper solutions, but in the long run:
- reduce parallel build performance
- obfuscate the code (after some time no-one will know which direction of the circle was the intentional one)
- bundle together stuff that actually should have no connection.

It is not surprising that so many researchers have found (in other languages) that files in circular imports are more likely to contain bugs.

Re: Advanced TTCN-3 usage [message #1738385 is a reply to message #1737643] Tue, 19 July 2016 11:44 Go to previous message
Gustavo Gonnet is currently offline Gustavo GonnetFriend
Messages: 34
Registered: October 2015
Location: Montreal, Quebec, Canada
interesting paper, thank you!
Previous Topic:Simple test case with CoAP
Next Topic:Catching dynamic testcase errors
Goto Forum:

Current Time: Fri Jun 22 19:22:39 GMT 2018

Powered by FUDForum. Page generated in 0.01867 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top