| Advanced TTCN-3 usage [message #1737643] |
Mon, 11 July 2016 14:29  |
 Kristof Szabados
Messages: 60
Registered: July 2015 |
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.
Right?
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.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02376 seconds
] 
Search
Help
Register
Login
Home
