Re: subdivide large .ttcn files for faster dev cycle

Hi Neels, I'm sorry, all I can really respond here is: Simply [request sysmocom] to get a faster machine for your development work. I'm certainly against starting to change the source code architecture to optimize compile speeds. This is 2024. not 1995. Right now the code is split based on logical, easy to understand reasons. If you start to split it just because your source code file size reached some magical limit, you end up constantly having to navigate between multiple files with no real guidance on whether something will be in BSC_Tests1.ttcn, BSC_Tests2.ttcn, etc. Last, but not least, the junit-xml generation includes the TTCN3 Module (== file) as part of the name. If you shift a test to another module, it looks like it's a new test. At that point you loose the test history in the test results analyzer, ... On Wed, Aug 28, 2024 at 02:21:08AM +0200, Neels Hofmeyr wrote: 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 time where people still mostly used machines with 8GB or even 4GB of RAM. You can turn that off at any time. But of course it will still have to recompile the one source file, and if that's only one you will not benefit from multiple CPUs/cores. In my experience, running the actual tests takes longer than building anyway? Some benchmarks here, on my T14 laptop with 7840U / 32 GB RAM: * 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 So slower initial build with slightly faster incremental build - not really worth it, IMHO. 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 is not yet 100% feature complete (but not too far either), and it remains to be seen how that performs at runtime - and of course it means all the existing C++ test ports also need a rewrite, which is pretty much a blocker. But according to the Eclipse TITAN project, that is their strategy for the future. Regards, Harald [1] https://gitlab.eclipse.org/eclipse/titan/titan.core/blob/master/usrguide/ja… -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)