Showing results for 
Search instead for 
Did you mean: 

Slow behaviour of an API program translated in VB.NET using VSTO

Valued Contributor
Valued Contributor

Hello Everyone,

given that at the moment I have really few experience using VSTO, I was trying to move a quite complex application written with the API programming tool inside Femap to Visual Studio, translating it into VB.NET language.

I get the application running in the correct way, but I face an extremelly slow behaviour using the .exe compiled file instead of the .bas file of the API programming tool. Initially I thought the problem was related to the different management of the arrays in the two languages, but I was wrong...

I've built an extremelly simple program called EXAMPLE.bas using API programming tool, that simply cycles over the elements of a FEMAP model doing absolutelly nothing except detecting the time elapsed to do the cycle. The same program have been traslated in VB.NET using a VSTO console application, building an EXAMPLE.exe file. The behaviour of the two programs is extremelly different: opening a simple model with 3600 elements the EXAMPLE.bas file takes 0.035s to run, the EXAMPLE.exe file more than 1.4s. In addition EXAMPLE.bas takes always the same time when running, EXAMPLE.exe takes a variable time instead (1.4s, 1.8s, 2.6s...).

In the Attachments I have placed the VSTO project and the EXAMPLE.bas.

Everywhere I read that FEMAP applications written in VB.NET should be quicker or at least not slower than .bas file, because they are compiled...

Is this a problem related to some VSTO setting I didn't do or what? Please, can someone help me?


Many thanks




Re: Slow behaviour of an API program translated in VB.NET using VSTO

Siemens Legend Siemens Legend
Siemens Legend

Hi Za,


While generally speaking, if all things are equal it's safe to assume that a compiled program will run faster than an interpreted program, it's not always correct to assume that porting your program from Femap VBA to an externally compiled language will result in a performance increase. Within the API programming window, you don't really encounter the same COM overhead as you would in an external devleopment environment. It can vary based on the type of call, but usually you'll see the biggest discrepancy in peformance with database-speciifc calls. 


The same rules that apply to efficient programming within the API window would apply doubly over COM - basically minimize your API calls (such as using GetAllArray and PutAllArray with elements).


At the end of the day, I wouldn't port an API program to an externally compiled one simply for performance improvements. Certain language-specific tasks may be faster, but it's also possible you negate those speed improvements with the additional COM overhead. Instead, the decision to port should be based on things like additional language features, UI framework options, integration with other codebases, etc, etc, etc.