Citect 2018 Startup Time

Hi community,

Does anyone know what Citect Studio does when it first launches the graphics builder (and performs some preload operation) and whether it's possible to speed this process up (or avoid it completely)?

Depending on the machine we're running on, it could take up to 10mins (or longer) for the graphics builder to become usefully responsive.

  • hello,

    Maybe he is update the projects.

    But does it always happen?
  • Hi Steve,

    I don't think this is supposed to happen, certainly not for 10 minutes.
    Have you tried a clean reinstall of Citect?
    Are you running on a supported environment (Windows version)?
    Can you see anyting in the Windows Event Logs or Citect log files?

    Regards,
    Patrick
  • Hi Steve,

    I agree with Patrick, 10 minutes is not normal.
    If Graphic Builder is started you see it is looping through projects / files (check bottom left stauts bar).
    Are you projects all local or maybe on a network share (and maybe not all accessible from some clients)?
    Also you could use a tool like ProcessMonitor to see why it takes so long.
  • My guess is that Citect is doing something at startup that involves the composite genies. As the number of composites (and pages using them) we have in our project has increased, so has the startup time. Throughout this period there are 'Keyboard' and 'Animation Point' prompts in the status bar of the graphics builder.

    A ProcMon dump seems to corroborate this. Starting Citect Studio produces the following:
    1. Lots of accessing various DBFs/NDX/INI in various projects for a short period (<2sec)
    ...followed by the 2a/2b sequence over and over again (for 10mins)...
    2a. CTDRAW32.EXE accessing a CTL or CTM at a specific file offset and reading a block of data (usually in extremely small 4bytes chunks)
    2b. CitectIDE.EXE accessing the associated project's PROJECT.CIT file (for a very short period; <0.1sec)

    The vast majority of the trace activity is CTDRAW32.EXE reading CTM files in small chunks, and it does this consistently for the entire duration (ie. there aren't any periods where it is not doing this).

    The problem is consistent across multiple machines with completely different builds; aside from all being Windows 10.
    Machines are 64bit i7 2.2GHz or better, 32GB RAM, 256GB SSD; or VMs of the same ilk.