1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Incredibly slow version V22 64-bit build 22061

Discussion in 'Using Alibre Design' started by clexpert, Jan 15, 2021.

  1. GIOV

    GIOV Alibre Super User

    simonb, HaroldL &DavidJ
    I am not an expert in this area but I can understand that there are two kinds of 3d CAD softwares:
    1.- The one specialized in giving mathematically very precise shapes;
    2.- The one specialized in giving a precise graphic for video games that is not necessarily precise.
    Each of the two types of programs has a specific hardware requirement.
    The dilemma is that AD is a program for engineering use, that is to say its objective is to give a mathematically precise form.
    I don't know if you read my link a few days ago about two big brothers, where this problem is described in detail.
    As I understand it, the only thing AD should do is to keep its character of engineering program, that is to achieve mathematically accurate shapes with the lowest possible weight of kb, improving its features such as the possibilities of shape sculpting and loft while keeping up to date with Direct X or Open GL. Nothing more.
    I would like someone to comment on this to see if I am right.
  2. simonb65

    simonb65 Alibre Super User

    There is no significant difference in precision between Alibre and other parametric graphic applications, irrespective of what their output files are exported into (i.e. Blender, 3DMax, etc). Alibre has constraints, that's it! The fundamental difference is that other applications don't get slower at each release. Other applications do not have performance issues when working with large models. Other applications don't noticeably slow down after an hour of adding geometry. There is a marked difference in performance just in Alibre between using Legacy vs HOOPS modes ... that difference 'should' be better in HOOPs as that is what has been chosen to take the product forward.

    Performance of an graphics application, whether editor or renderer is down to optimisation, and process.

    I ask you a few rhetorical questions for your thoughts ... when I add about 20 sketches to a model, and generate 20 features from them, why does the application wait 2-3 seconds between each mouse click when I try and add a dimension? What is the application doing that takes 3 seconds? Why didn't it take 3 seconds on the first sketch, but it does after say 20+? Is it re-calculating things it has already calculated once (that haven't actually changed)? Does it not cache calculated information?

    The answer to the last one in most data processing intense applications (and graphic engines) is that they hugely rely of pre-processed data, or pools of worker threads in the background that monitor changes on data structures and refresh the maths before the main application needs to use it. Even using the right kind of data maps and dictionaries to quickly look up items (instead of iterating through lists).

    Example: You have the following dependencies ... A->B->C->D->E->F->G. If you change E, it doesn't need to recalculate A thru D as they haven't changed. Now you add a sketch to the end of a feature tree (lets say H), then it should be as quick as when you created A, because everything up to G hasn't changed, so again, why does Alibre seem to re-calculate from A thru G again? (It may not be, but based on the symptomatic behaviour, that is my experienced assumption).

    I understand why the hover picking is quick, that's because it most probably utilising a framebuffer within the GPU to instantly provide what's under the mouse pointer. It's the other processing that I don't understand.

    If you can explain, or have comment, @GIOV on why Alibre is much slower now than it used to be, based on the fact that we don't have any more functionality or significant geometry processing than we did 5+ years ago, then I would be interested to hear your views.

    I agree, but that doesn't mean it has to take so long to do simple edits or additions! Most of the visual stuff added with HOOPS is only (should be) GPU intensive. So that doesn't leave the main application much to do other than handle user interaction and manage the model geometry data (which as I mentioned before does not need completely re-calculating every time to change something down the feature tree).
  3. JST

    JST Alibre Super User

    My understanding from other comments here by Max etc, and observation, is that Alibre always recalculates, presumably to avoid having to keep track of umpty-lump intermediate results. It's a sound strategy, so long as the calculations are shorter duration than the look-up time.

    Certainly, I have used some features, such as projected sketches that are box-checked to maintain source geometry. A few of those will reduce the apparent performance of a fast computer to nearly "serial 'phone modem" speeds.

    I will note that any basic redesign of Alibre in that way would very likely result in zero new versions for a year. No bug fixes, no nothing. I do not know the staffing size at Alibre (although I can find out through other sources), but it takes no genius to guess it is not enough to handle that quickly.

    I don't know of a workaround. There are no "subassemblies" at the sketch/part level. Having 20 sketches? Your 3 seconds sounds good. I have had 5 to 10 seconds.
  4. simonb65

    simonb65 Alibre Super User

    Just to add further to the thoughts on performance ... If I run my benchmark tests With and Without a GUI, why does saving the assembly take the best part of 7 minutes when the GUI is visible and less than 2 seconds without the GUI? Same data, same basic operation required. The status bar bottom left (during a SaveAs call to the API) shows "Working" then "Updating Annotations and redlines" during the save operation ...

    What does it need to calculate and update during a save? Nothing has changed?
    Why is time saving so vastly different with and without the GUI?

    Typical timings of my benchmark test (programmatically create and add 1 PCB, then add 400 existing small parts to an assembly), with and without the GUI invoked ...

    HOOPS Mode:

    Legacy Mode:

    Whichever way you look at the figures, performance wise, there is something fundamentally wrong with the core process of Alibre Design. Operations that need no further geometry processing are being processed. HOOPS mode is demonstrated to be significantly slower than Legacy mode in both adding items and hugely slower during save operations! The time to save geometry should NOT be any different just because a UI is visible!

    I'm not asking for support/fellow user answers or workarounds, I'm just pointing out (hopefully to the Alibre dev team) that something is wrong and seriously needs to be addressed here ... sooner rather than later.
    Last edited: Feb 22, 2021 at 10:49 AM
    NateLiqGrav and GIOV like this.
  5. JST

    JST Alibre Super User

    GUI invoked means just what?

    I had thought you meant legacy, obviously not.
  6. simonb65

    simonb65 Alibre Super User

    When you use Alibre from an external tool/application through the API, the external application needs to 'connect' or 'hook' into the Alibre Design process.

    When you do this, you have the choice of creating an AD process with or without the visible user interface (the home screen, part workspace, etc you normally see if you open Alibre in windows). 'Invoking' is the act of programmatically creating the AD process. Without a GUI, means just that. An Alibre process is created in the background but it only gives you access to Alibres core 'engine', the same engine you can access through Alibre Script, so in this case you can't physically see anything, but you can do everything programmatically (that the API allows!) that you normally can.

    In both cases if you opened up Task Manager, you would see the Alibre Design.exe task running.

Share This Page