First use startup speed for STYLE and MTEXT

On my computer there was a delay of close to 30 seconds the first time I call the STYLE command and a similar delay the first time I call the MTEXT command.  During that time the computer appears to be completely unresponsive.  There is very little activity on the hard drive light.  Changing to an SSD cut the delays by about half.  A 30 second delay, or even a 15 second delay, seems inappropriate, but it could be normal.  Does anyone else see the delay?  If not, is there a setting or other configuration item that I should look at?  Thanks.

Comments

  • Hallo, my computer has the same problem, also with SSD.
     I have 223 fonts and i think, thats the problem.
    Christian
  • I have 165 fonts installed (out of several thousand that are stored on the disks).  The start-up time does not seem to change for me whether there are 165 or 400 fonts installed.  Autocad 2010 has no visible delay when I start the MTEXT command for the first time.  This is when I start Autocad 2010 and run the MTEXT command as soon as program is loaded so it cannot be that Autocad is inspecting fonts as a background task.  There is no practical way to reduce the number of fonts -- all the fonts I have installed are used regularly.

    This looks like a time-out situation to me, but there is nothing reported in the logs other than a few font substitutions from the default.fmp file.  Commenting out all the substitutions in default.fmp does not change the delay. 
  • In case your SRCHPATH setting refers to network paths: does the delay go away when temporarily removing these paths?
  • On my computer there was a delay of close to 30 seconds the first time I call the STYLE command and a similar delay the first time I call the MTEXT command..

    I, too, notice a delay (not 30, or even 15 seconds, but around 10 seconds) when MTEXT is first invoked. Had me curious as well.
    Subsequent invocations are instantaneous.
  • I see only a 2 or 3 second delay the first time I edit an Mtext. And it doesn't happen each time I start up Bricscad, but only the first time I do so after re-booting Windows. I re-boot Windows every day, so the delay is a regular morning event. But it's not a problem for me, since it's so short in my case.

    I have no network folders listed anywhere in Settings. Perhaps that's why my delay is much shorter, as Hans suggested.

    I have 400 system fonts installed, and 90 SHX fonts. But I rarely have more than 5 or 10 text styles defined in any DWG file, which I gather is far fewer than many people have. I don't know whether that has any effect on the delay time.

    Because of what Martin said about Autocad 2010, I just checked and found the same 2 or 3 second delay in Autocad 2014 with a similar set of search paths and using the same DWG file.
  • The problem are the network- folders in the searchpath.
    I have networkfolders with special lines and symbols and the network is slow.
    Christian
  • I see only a 2 or 3 second delay the first time I edit an Mtext. And it doesn't happen each time I start up Bricscad, but only the first time I do so after re-booting Windows...

    I can confirm delay (10 sec.s here) is only after reboot. No network folders here.
    This bug (if it can be defined as such), I would classify as 'minor annoyance'.
  • In case your SRCHPATH setting refers to network paths: does the delay go away when temporarily removing these paths?

    Yes, the delay goes away if I remove the path to the network share with the fonts. 

    The network here is gigabit and was not in use by others when I tested.  The server is Ubuntu 14.04.  I tried keeping the path to S:\_Fonts but removing everything from that file except the .shx files, but the delay remained.  We also tested on another computer by moving the font folder to the local drive.  There was no delay.



  • Yes, the delay goes away if I remove the path to the network share with the fonts. 

    The network here is gigabit and was not in use by others when I tested.  The server is Ubuntu 14.04.  I tried keeping the path to S:\_Fonts but removing everything from that file except the .shx files, but the delay remained.  We also tested on another computer by moving the font folder to the local drive.  There was no delay.




    Perhaps you could mirror the contents of the network fonts folder to a local drive. ROBOCOPY is a useful tool for doing this. You can set it to mirror the contents of folders. Once files are copied the first time it is very fast. I've used it numerous times to synch the company CAD library to the local drive of laptop users, so they continue to use CAD away from the office.

    I would think it is all the handshaking across the network that is causing the delay. A folder with lots of small files will be slower to access than a folder with a few large files. Perhaps their are some adjustment that could be made on the server to improve this.

    Regards,

    Jason Bourhill

    CAD Concepts 


  • @Jason Bourhill

    Thanks for the suggestion.  It would certainly be possible to use local copies of the font files, but that would not be "best practices".  A large company needs to have a central repository so that everyone has access to the same data and so that IT does not have to go station to station doing frequent manual updates.  With a small company like mine there is no IT staff so it falls to me to do any manual updates.  An automated utility that updates a local copy of master data daily will still cause a delay.  It may not be as visible as having to wait 30 seconds with your computer locked when you start a command for the first time, but it will still be lost time.  For computers that are not on the network the ROBOCOPY approach makes a lot of sense, but it should not be necessary for desktop computers.

    If I must I will go to local copies of font files, but I have to believe that this is a programming issue since competing programs accessing the same data on the same network share do not have any visible delay.  I don't know enough about the internal programming of Bricscad to know if this is easy to fix or impossible to fix.  Either way it is good to have asked the question.
  • @H Martin Shoemaker:


    An automated utility that updates a local copy of master data daily will still cause a delay.  It may not be as visible as having to wait 30 seconds with your computer locked when you start a command for the first time, but it will still be lost time.  For computers that are not on the network the ROBOCOPY approach makes a lot of sense, but it should not be necessary for desktop computers.



    Are you familiar with Windows' offline files cache? Things like fonts and other shared files that are accessed frequently really should be cached locally, and using the cache means there is no delay and it is all automatic. The only real work is setting it up. Even setup is pretty easy if you just make entire folder hierarchies available offline, but I recommend to take some care and only cache the files and folders actually needed. As luck would have it, I wrote the (shareware) RoboCache utility for exactly this purpose.
  • @Owen Wengerd

    Thanks.  I had not thought of the offline files cache.  I'll look at RoboCache. 

    While local caching is probably the correct thing to do (and probably really is "best practices") I doubt that it is common in most shops, and I suspect that it is either an unknown or it is outlawed by IT in many shops, especially where IT is a separate department that has no clue what a CAD program is.  Locking things down "so the users can't mess them up" seems to be quite common with IT.

    I still think this issue needs to be addressed in the Bricscad code.  There is nothing that I know of in the documentation that mentions an issue with networked files and there is no pop-up or other status indicator when Bricscad hangs -- the computer simple becomes unresponsive.  The competition does not have a visible delay the first time MTEXT is called with the same pathing to a network share. 


  • I agree that the BricsCAD freezing issue should be addressed. I recommend to create a support request for this to ensure that it gets properly investigated.
This discussion has been closed.

Howdy, Stranger!

It looks like you're new here. Click one of the buttons on the top bar to get involved!