1 of 1 people found this helpful
I've written a VBA (Excel) program, that extracts all properties of our library and it runs about 6 minutes for approx. 18,200 parts. I also tried your C#-program without the console-output and without extraction of cell-, symbol- and gate-information. It runs about 2 minutes longer. The library was on a local drive, because a network drive probably wouldn't be fast enough. In my case it doesn't matter.
I remember, that I recently got a MakeDxDataBook script from mentor, that uses automation for the first time. And this was very slow. With HKP, it is significant faster.
There is IMHO nothing in your program, that can be made faster. The best recommendation is to use a faster drive (no network) or export HKP, as long as it is supported by Mentor.
Re speed of VBA: This would be the first VBA script that I know that beats a C# program. Would you mind sharing it or is it confidential?
Re hkp: This program is part of our attempt to learn to live without hkp files. So far it doesn't look like we can. So we can only continue to try to pressure Mentor to keep some text file export, be it hkp, xml or something else.
Re network drive: We maintain a large pool of workstations, unfortunately there's no way to take the library off the network drive.
There is nothing special in this VBA-programm. It travels through collection of partitions, parts and properties. Maybe, that the COM interface is a little bit faster than the .Net? I don't know.
Just try the attached VBS-File. It runs in seconds, not minutes.
And regarding netdrives and HKP: I'm full with you. You are not alone with your problems. I also hope, that Mentor will understand, why we need external tools. HKP or ASCII may be equal, but nearly each designer has written a couple of tools and don't want to rewrite everything. So it would be better to check the HKP input data instead of replacing the format.
PDBEditor.zip 1.0 KB
After debugging for a while I found out what the problem was.
.NET is per default multithreaded and with COM this causes synchronization overhead.
The solution in this case is simply to apply the STAThread-Attribute to the main function and I get a speedup of factor 10 when working on a local drive. (When working on a network drive, the gain is dwarfed by the network delays, unfortunately.)
Here's the new code. I also simplified it and changed it so that it produces the same output your script does.
Since with out small library it takes only zero-point-something seconds, maybe you could run it on your library again and compare it to your script?
Thanks a whole lot for your help!
PdbLoader.zip 109.1 KB
5 Seconds for 18300 parts. Great.
Over here, with the full output (i.e. the mappings) I save about 90s.
With the library on disk it's the difference between 2:50min and 1:20min, with the library on a network drive it's unfortunately the difference between 16:50min and ca. 15min. :-((
This, compared to the few seconds the library services take when saving a hkp from the network based library.
Well, one more argument to bring up when mentor tells us that we can do everything using automation.
Anyway, thanks a lot for helping me!