My thought’s on Martin’s advice…

>Try to create small scraps (max 100 m?). And try to create new .th2 file for each one scrap. This will reduce opening time much!

Small scraps are good, and fast to load and render, but one scrap per file would seem to be excessive unless you are dealing with extra large scraps.

By limiting to one scrap per file, you are removing the significant advantage of automatic scrap joins that Therion enforces when points and line points from adjacent scraps are snapped to the same location.  And in addition you will have many more ‘input drawing.th2’ statements and ‘join scrap1 scrap2’ statements.

I am looking at a small cave I surveyed two weeks ago, just under 130m in length.  Parts of it are a little bit complex, and I am drawing at 1:250 instead of my usual 1:500 or 1:1000, so scraps have been broken into smaller pieces than would be typical and so I have more of them.  It is much more detailed than my typical effort.

• I made 3 PocketTopo files, because the plan and elevation complexities made it expedient to start new files (in other cases 500-1000m per PocketTopo would be a typical upper limit).
• That led to 3 survey.th files, 3 plan.th2 files and 3 elev.th2 files.
• Between the plan and elevation projections, the drawing files have 32 scraps (5-6 scraps per file, 4 of them are cross sections), and total 2800 lines (292-790 lines per file).
• By maximising scraps per file, I estimate I have saved myself 24 input statements, and 20 - 25 join statements, and in addition, I am mostly drawing with the context of adjacent scraps in full view.

If this was part of a large cave drawn at 1:1000, there might have been less than one third the number of scraps (still a lot, but required to avoid single scraps passing over or under themselves).  The general point is, in a large cave system, one scrap per file would seem to create a lot of unnecessary work and input/join statements.

And I doubt the number of scraps per file is what actually causes the reduction in performance.

I would expect it is more related to the number of entities or number of lines within the th2 file, and the size of any xvi or image files loaded.  From memory the rendering starts to become noticeably slower at 1000-1500 lines per th2 file, and intolerable at 3000 lines per th2 file (assuming a minimal xvi image).  This will vary from computer to computer, and your tolerance to waiting.

My rules of thumb are;

• Minimise the size of survey trip files (limits size of and delay due to xvi and sketch files)  I find 200 - 600m is good - same as Martins advice, we just have different thresholds.
• Make as many scraps as you want or need in each th2 file, and avoid more than one th2 file per survey trip file if you can help it – differs from Martins advice – almost opposite!
• Once your th2 file reaches about 1500 lines, start considering another th2 file.

Having said that, I don’t think there are any absolute limits, it’s just a matter of preference.

Bruce