ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
ni.com checkout is currently experiencing issues.
Support teams are actively working on the resolution.
09-30-2014 09:29 PM
In my experience the real limitation is the IDE. My large actor-based projects typically have many unique actors rather than multiple copies of the same actor. I've never noticed significant delays with any of my message passing, even with time critical code. The underlying queues are rock solid and highly scalable.
However, I routinely lose large chunks of time waiting for the IDE when loading classes, editing class properties, etc. Unfortunately IDE sluggishness seems to scale exponentially with the number of classes in memory...
10-01-2014 06:09 AM
Not to forget about the IDE crashes. When I work on old legacy code which makes no use of classes two weeks might go by before I get happily greeted encouraging me to make some people at NI very happy by uploading my error log. Yesterday working on AF I had six of those greetings ...
10-01-2014 10:15 AM
Mathis wrote:
Not to forget about the IDE crashes. When I work on old legacy code which makes no use of classes two weeks might go by before I get happily greeted encouraging me to make some people at NI very happy by uploading my error log. Yesterday working on AF I had six of those greetings ...
In my experience the real limitation is the IDE. My large actor-based projects typically have many unique actors rather than multiple copies of the same actor. I've never noticed significant delays with any of my message passing, even with time critical code. The underlying queues are rock solid and highly scalable.
However, I routinely lose large chunks of time waiting for the IDE when loading classes, editing class properties, etc. Unfortunately IDE sluggishness seems to scale exponentially with the number of classes in memory...
I second both of these but probably an issue for another thread I will say every year when a new version of LV comes out, i keep expecting some update on these issues but it doesn't seem to be a priority.
10-01-2014 11:28 AM
Jed,
It is completely worthwhile to continue to bring this up. David Staab brought this up I believe somewhere else (for whatever reason I can't seem to find the post now) and I am seeing the exact same behavior. I have dismissed these errors until recently as just an annoyance, but it is worrying when I see that the crashing is scaling with the number of classes present in the project. Maybe there is a critical threshold of complaining at which NI will direct some resources toward this issue. So, it is always worth it to bring this up. And it is apropo for this post given that we are looking at large applications with lots of actors (i.e. classes), so kudos to all of you who continue to point this out.
And thanks to wcolleto - this is an awesome test case for the actor framework and it instills some faith in me (given that I seem to be too lazy to actually do some of the testing described above) that the AF will scale robustly with application size. Thus far I have had no need for an application utilizing > 20 actors, but it's good to know that things seem to continue functioning as expected beyond 100 actors.
Cheers, Matt
10-01-2014 11:58 AM
mtat76 wrote:
Maybe there is a critical threshold of complaining at which NI will direct some resources toward this issue.
That threshold was reached long ago. The hangs and crashes have been the primary concern for the last two releases of LabVIEW, trumping pretty much everything else. Then number of hangs and crashes has decreased considerably, but none of them are trivial, and most are requiring replacing some of the original editing systems of LabVIEW -- a particularly error prone process when you consider 20+ years of code built on top of them, so we have been cautious in each modification. More updates in this area will be coming for the next few years.
10-01-2014 08:33 PM
The hangs and crashes have been the primary concern for the last two releases of LabVIEW
That's good to know.
I would like to add however that I would *much* prefer an IDE that crashes once or twice a day but actually lets me work efficiently with 500 classes in memory, rather than an IDE that never crashes but takes 3 minutes to open the class properties dialog. But that's probably just me!