My vague idea for subdivision was to group by meaningful themes, for example, putting all the "cnpool" tests in a separate file, all segfault triggering tests in another; somesuch could even help readability...
In my experience, running the actual tests takes longer than building anyway?
Hm, for me, usually the test runs I do are very rapid. Well, it may be subjective, but the CPU running hot so much is annoying to me, and the wait always feels just a bit too long. For me it's an itch that could be scratched, slight bummer that you still disagree =)
That division in multiple files is actually what *we explicitly requested* TITAN to do, in order to reduce the RAM requirements o the compiler. Probably back at a
Oh, I didn't know that! I thought the implicit division in multiple compilation units is pretty cool, and every now and then also hits ccache well, too, but often I wish it could be sub-dividing more intelligently, to favor that as many sub-units as possible remain identical. Currently, often just a small change in some function that happens to be at the top of the .ttcn file causes all sub-parts to be recompiled, instead of just, say, part 2. Sometimes when tweaking I try to cheat so that the line numbers don't change further down in the file. (Maybe I'm naive there, I have no knowledge how the subdivision is done.)
- using the "-U 8" of splitting every source file in 8 chunks
** rebuilding the BSC test suite (arguably one of our larger ones) from scratch takes 51 seconds on my T14 laptop here. ** rebuilding after 'touch BSC_Tests.ttcn' takes 17 seconds.
- removing the "-U 8"
** rebuilding the BSC test suite from scratc takes 1:22 minutes ** rebuilding after 'touch BSC_Tests.ttcn' takes 14 seconds
interesting!
FYI, the long build times of the TTCN3--titan-->C++--gcc-->executable are one of the motivations of why TITAN has been working on reimplementing a new compiler/runtime in Java during the past years [1]. It
In Java .. To gain speed ... My past experience with Java is that it feels slow, like you can watch it think, like a train station departure info board settling to a new frame. Compilation of .class files is NOT fast in my xp. And always the Classpath and jar files and weird build systems... I'm frowning a bit, I had hoped that I had left the Java world behind for good.
I wonder if it could be feasible to write an interpreter for ttcn, instead of generating code from it that is then again compiled before running... Even if the interpreter is not lightning fast, it would completely eliminate that wait time from .ttcn to running the test. There is usually plenty of idle time during test runs, anyway, seems silly to optimize the execution speed.
Thanks for the cool feedback!
~N