Slow performance in AutoCAD after VLIDE is opened

[doaiena]

Yesterday i stumbled on some very weird behaviour in AutoCAD, after the VLIDE window has been opened.

Once VLIDE is opened, AutoCAD's performance becomes drastically worse. Closing the VLIDE has no effect. The only way to restore ACAD's original performance is to restart the application.

Some backstory first.
For years i have been coding on an old quad core workstation with 4GB of RAM. I recently transitioned to a modern six core system with 16GB of RAM. Because of the difference in IPC and clock speed, i was expecting around a 2x performance increase. The new system is indeed x2 faster than the old one before you open the VLIDE. Once VLIDE is opened though, the newer system is x2 slower than the old computer, which was a surprise.

 

After a few hours of benchmarking, the results are:

 

Old PC loses around 60% performance once VLIDE is opened
C2Q @2.8Ghz, 4GB
Windows 7 x64
ACAD 2018.1.1

My bencmark goes from:
1.132s
0.936s
0.952s
0.936s
---
to:
1.466s
1.451s
1.638s
1.451s

Cadalyst benchmark 2015 v5.5: 17 min -> 27 min (Single Loop Time)
====================

 

New PC loses around 500% performance once VLIDE is opened
R5 @4.3Ghz, 16GB
Windows 10 x64

ACAD 2018.1.1

My bencmark goes from:
0.672s
0.609s
0.609s
0.594s
---
to:
3.05s
3.969s
3.25s
3.047s

Cadalyst benchmark 2015 v5.5: 9 min -> 37 min (Single Loop Time)

====================

 

I also had a chance to test a colleague's system for a few minutes.

Colleague's PC loses around 400% performance once VLIDE is opened
I don't know the specs for his computer (forgot to check)

Windows 10 x64

ACAD 2019

I couldn't record any numerical data, but a quick calculation slowed a 4x performance loss

====================

 

 

From what i experienced, i think that Windows 10 has something to do with the performance loss, but i can't find out what and why. I don't have access to other computers with AutoCAD to perform more testing, to be sure if its a Windows related issue, or just ACAD.

 

On Win10 i have tried to:
- disable network adapter
- disable transparency and visual effects

- disable SMT (CPU multithreading)
- run as administrator

- run in compatibility mode

- disable hardware acceleration in ACAD

- set "HIGH" priority for the acad.exe process

- probably a lot more things i can't remember now


So basically that's it. Nothing i tried has any effect on performance at all. Once VLIDE is opened, there is a drastic decrease in performance, and the only way to "fix" that is to restart ACAD and never open VLIDE.
My sample size of computers is too small to make any real conclusions, but so far:
Win7 - 50% performance loss
Win10 - 400-500% performance loss

I would be very thankfull if you guys can share some knowledge on this matter. I have no idea what to check for anymore. Any help to clear out this matter would be of great value.

 

Thank you in advance.

Edited February 29, 2020 by doaiena

[rlx]

Somewhere in the cloudy part of my last functioning braincell I remember AutoCad 2018 is a bad bad AutoCad , instable and lazy. Either re-install , see if there are updates or upgrade (or even downgrade) to other version. Think if you google on AutoCad 2018 buglist or problems you will find there are more people having problems with this version. I believe I once have called this version Autocad Vista , after the windows version microsoft wants to forget.

 

https://forums.autodesk.com/t5/autocad-forum/seeing-major-performance-issues-and-instability-in-2018/td-p/7897519

 

https://forums.autodesk.com/t5/autocad-forum/2018-is-the-worst-release-ever-unbelievable/td-p/7904961

 

 

Edited March 1, 2020 by rlx

[doaiena]

Thanks for your input. I remember ACAD2014 being a lot faster than 2018, so i think you are spot on about ACAD2018. I saw the same VLIDE performance issue with ACAD2019. Can you confirm or deny my findings on your version of ACAD?

I just did the most basic test. I stuck a timer at the beggining of a function and just report it at the end.

[rlx]

It is important to know if it is VLIDE itself that is causing this issue or if one of your codes is responsible. For me a code is good if the response time is acceptable. I don't care about milli sec's. Only if a program becomes unresponsive for a long time I try to find a way to speed it up. If your code uses a lot of disk operations or a huge data list consider breaking it down and use the (GC) function to release unused memory and flushing data caches. If a script normally does one dwg per sec ... fine , if it suddenly needs 1 minute I get concerned.

 

My company decided to outsource our network structure to a commercial party (oh joy) and the effect was dramatic and not in a positive way. Even saving drawings to my local harddrive has allmost no effect in speed because of the limited bandwidth and everything I do is still monitored. Just to say , it can be VLIDE or big bad AutoCad but other factors like bad code / infrastructure can be responsible.

 

Try to start with none or as little lisp routines in your start up and then see if just starting VLIDE (with no files preloaded) gives you trouble. If loading and saving drawings is fast enough , its maybe not the editor but one of your codes slowing things down. Even your profile can mess things up by trying to look for paths that no longer exist because IT decided to move some stuff to a new server. This happens to me a lot at work so I was so fed up with that , that I removed all network paths and it had a very positive effect on most my lisp routines. But loading drawings from a project folder is still very irritating.

 

It is known that some commands  / code runs faster than other , like using the 'cons' function or 'append' when creating lists. This may be true in theory , usually it only matters when processing large amounts of data. AutoCad has a few memory settings , don't have them I my head right now , alloc or something , maybe increasing memory available for your routines can help too...

[doaiena]

I agree with what you have written. It was just an observation that i made. A piece of code behaves wildly different (performance wise), depending on whether VLIDE is opened or not (under Win10). No system calls, no network or IO operations. The part that slows down the most has a lot of internal function calls, Vlisp functions, xdata manipulation, list manipulation. It's weird, that just opening the VLIDE window would have any effect at all on code performance.

Edited March 1, 2020 by doaiena

[BIGAL]

The dumb question if its a problem why are you even running VLIDE ? Are you using it to load lisps then use the type it method (load "mylisp") or appload, if your lisps are in a support directory you can use just filename and not worry about directory. All the company lisps are in menus or autoloaded.

 

I write about 90 % without vlide testing as I go and use VLide when I just can not see is wrong.

[doaiena]

I am running VLIDE to write and debug code, follow variables, examine objects, write snippets of code directly in the console, manually feed data in variables to test functions as i write them etc... It's not such a big deal to be honest. I just noticed the slowdown and wanted to check with you guys to see if it was a problem on my end, or it's working as expected.

[rlx]

I have 3 screens on my normal computer , only i5 cpu I'm afraid , and left screen is for email etc , middle for AutoCad and right screen has most of the time my VLIDE in it. Mainly because I constantly tweak my routines or just for fun when I'm bored with the work I'm doing. It never bugs me , well, almost never , have one routine , my batch app and when I run it with VLIDE open it always triggers the error trapping , but without VLIDE open the routine runs just fine. Probably need to do some better error trapping because it never shows me where it tripped , just that an error occurred. But for the rest I'm happy to have my editor open all the time. (makes me look smarter hahaha)

Edited March 2, 2020 by rlx

[BIGAL]

I have converted to notepad++ best thing as you write code can check bracket matching as you go, I tend to cut and paste code to command lines so test as I go.