2018.2
- Thread starter Max
- Start date
Lew_Merrick
Guest
Ah yes! But how much "polishing" has been done?
domcm
Senior Member
@Max
The performance improvements are great news! I have an assembly with many constraints tied to a 20 sheet drawing. Opening the drawing takes over 2 minutes on an i7-6700 @ 3.7 Ghz. Reprojecting all of the drawing views takes over 4 minutes. I'm sure there are other users seeing larger delays.
The performance improvements are great news! I have an assembly with many constraints tied to a 20 sheet drawing. Opening the drawing takes over 2 minutes on an i7-6700 @ 3.7 Ghz. Reprojecting all of the drawing views takes over 4 minutes. I'm sure there are other users seeing larger delays.
swertel
Alibre Super User
Are you implying that all we got so far was the "spit"?
Lew_Merrick
Guest
No, but I am saying that a whole lot of "polishing" is needed!
MKR
Senior Member
I think the performance problem is hard/impossible to solve when Alibre is not supporting multi-core.
Last edited:
ajayre
Alibre Super User
Did you submit them to support?
HaroldL
Alibre Super User
I'll agree with that. Seems like scripting is the new hot item for Alibre Design.
Looking at the suggestion page there are some enhancements that have been implemented (to some degree) already but have not had so much as a comment posted. Someone should go thru the list and do a little status updating
We're fortunate to have ajayre working with us on Alibre Script. While Alibre Script is certainly an important feature to us and many customers, our in-house development team focuses their time on enhancements/bug fixes/performance improvements for the core feature set of Alibre Design.
Multi-threading support presupposes that multi-threading is the solution to a problem. For example, if assemblies open slowly on large assemblies, you might think "throw multi-threading at it."
In reality, performance is often related to inefficient algorithms that need to be addressed. We're making progress with optimizing some of these algorithms as you can see in the 2018.2 update notes.
Quite a few solving processes used for parametric modeling are by nature very linear and cannot take advantage of multi-threading. This is not to say that multi-threading can't help with performance in Alibre. Drawings with many views, for example, could benefit from multi-threading.
In some cases, multi-threading might make an operation slower, and in other cases it will make operations faster. We encourage users with performance issues to submit tickets to our support team for review - that will help us find out specifically what the issue is and help us determine in the future if multi-threading could be used or if we need to optimize the algorithms further for that specific issue.
NateLiquidGravity
Alibre Super User
Looks like a good amount of improvement! Alibre is really on a roll now. I can't wait to try it out.
These are two bugs I submitted so I'm glad they are getting fixed.
JST
Alibre Super User
Everything I do seems to be one-off, and I have seen little to no use for scripting.
That's not to say that it might not be useful later, or even soon......I might want it tomorrow. But please don't let the cool new whiz-bang scripting stuff overshadow basic improvements, and fixes to stuff that really needs it (working directories, library support of some sort, and better error messages, for instance).
If multi-threading does not help, OK.... Figured it might help with speed of rendering and rotations, etc, similar to what it does for keyshot, but if not, OK.
That's not to say that it might not be useful later, or even soon......I might want it tomorrow. But please don't let the cool new whiz-bang scripting stuff overshadow basic improvements, and fixes to stuff that really needs it (working directories, library support of some sort, and better error messages, for instance).
If multi-threading does not help, OK.... Figured it might help with speed of rendering and rotations, etc, similar to what it does for keyshot, but if not, OK.
BobSchaefer
Senior Member
Hey guys, I wouldn't freak out that a lot of resources are being "wasted" on the scripting feature. Reading between the lines of what Max said and what ajayre have said, it sounds like the resources allocated to this are ajayre alone. What you're seeing is him getting a lot of feedback and able to fix/implement a lot of little things, it just looks like a lot of stuff because they were probably mostly low hanging fruit that he could bang out in just a couple hours (if that) each.
Our Script development and regular development are not the same teams, so there is no tradeoff between Script features and regular features. Multi-threading can help in some cases, and in others would not help. It really depends on the exact thing going on. For example, to you, it may feel like "this 1000 part assembly is slow to load". To us, that action might look like:
1) Read file IO
2) Set ACIS entities
3) Retrieve meshes or re-mesh model
4) Set configurations
5) ...
...
15) Display model
Point is that there's a lot going on under the hood, and often we'll find that item 9) of 15) was coded a while ago with assumptions that are no longer correct. I'll give a real-world example - you right click on a part in an assembly > Show in Design Explorer. That command was made almost 2 decades ago. It was paiiiiiiinfully slow and time scaled with the number of assembly parts. It might take 2 minutes with a 1000 part assembly - clearly unacceptable. 7 ish years ago, we changed the search algorithm to a modern approach and now it's very fast.
"Performance" is typically a matter of finding, identifying, and changing these kinds of things, and there are classes of these things that benefit from multiple cores and classes that do not.
1) Read file IO
2) Set ACIS entities
3) Retrieve meshes or re-mesh model
4) Set configurations
5) ...
...
15) Display model
Point is that there's a lot going on under the hood, and often we'll find that item 9) of 15) was coded a while ago with assumptions that are no longer correct. I'll give a real-world example - you right click on a part in an assembly > Show in Design Explorer. That command was made almost 2 decades ago. It was paiiiiiiinfully slow and time scaled with the number of assembly parts. It might take 2 minutes with a 1000 part assembly - clearly unacceptable. 7 ish years ago, we changed the search algorithm to a modern approach and now it's very fast.
"Performance" is typically a matter of finding, identifying, and changing these kinds of things, and there are classes of these things that benefit from multiple cores and classes that do not.
This ^
We do have some development to enable new Script features, typically by creating new APIs for Script to consume, but that's quite low hanging for our team as well and doesn't take an appreciable amount of time.
bigseb
Alibre Super User
Perhaps my post has been misunderstood...
I like the whole scripting thing (I can't use it but I can see its potential). However there are other suggestions that have been around for a long time. Andy did a ton of work on Wizoscript (all of it?) so what else has been going on behind the scenes?
Not taking a dig at Alibre as they have had a lot of things to do since the re-takeover but as a user that has been making suggestions for many years I find myself asking, "When?"
I like the whole scripting thing (I can't use it but I can see its potential). However there are other suggestions that have been around for a long time. Andy did a ton of work on Wizoscript (all of it?) so what else has been going on behind the scenes?
Not taking a dig at Alibre as they have had a lot of things to do since the re-takeover but as a user that has been making suggestions for many years I find myself asking, "When?"