#619 Made TreeView stable

Merged, abandoned or rejected pull requests are moved here to clear the main Pull Requests forum.
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: #619 Made TreeView stable

Post by vejmarie »

I have this issues too and I am working on it. I discussed quickly with Ickby a few days ago.

The key issue is that the new App::Part object is adding 7 new objects instead of one like in the past. 6 objects are related to the coordinate system.
I do have a branch on my system which is eliminating most of these issues, and was expecting to release patches during the week (I do have a long haul flight tomorrow).

So jut wait the end of the week and you will be able to test a new branch which shall fix most of these things. I discovered it while reading a STEP file which took me about 19 hours to be opened.

By the way I also added an addObjects function with an (s) which is accelerating a lot this loop and you will see a performance boost of about x7 just by this fix. But this is exposing bottleneck either into the GetUniqueObjectName function which is looping on the global tree strings.

I was expecting issues by moving to new PartDesign but we will have most of them fixed pretty soon.
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: #619 Made TreeView stable

Post by vejmarie »

wmayer wrote:Today I found a major performance regression with the new tree view. In issue #1999 you will find the file FreeCadProblem.step which takes 15 minutes to load in release mode. For testing purposes and to be sure it's caused by this PR I reverted all recent changes of Tree.cpp and Tree.h and then the load time was OK again -- which is 30 seconds.

When loading the STEP file then from the importer this block in ImportOCAF.cpp seems to take forever (in debug mode):

Code: Select all

        if (!localValue.empty()) {
            pcPart = static_cast<App::Part*>(doc->addObject("App::Part",name.c_str()));

            // localValue contain the object that I must add to the local Part
            // I must add the PartOrigin and the Part itself
            for (std::size_t i=0; i<localValue.size(); i++) {
                pcPart->addObject(localValue[i]);
            }

            lValue.push_back(pcPart);
        }
Add this code to GroupExtension.cpp

Code: Select all

void GroupExtension::addObjects(std::vector<App::DocumentObject*> obj)
{
        for(int unsigned i=0;i<obj.size();i++){
             if (!allowObject(obj[i]))
                return;
             //only one group per object
            auto *group = App::GroupExtension::getGroupOfObject(obj[i]);
            if(group && group != getExtendedObject())
                group->getExtensionByType<App::GroupExtension>()->removeObject(obj[i]);
        }
        if (!hasObject(obj[0])) {
                std::vector<DocumentObject*> grp = Group.getValues();
                for(int unsigned i=0;i<obj.size();i++)
                        grp.push_back(obj[i]);
                Group.setValues(grp);
        }

}
And into GroupExtension.h

Code: Select all

    virtual void addObjects(std::vector<App::DocumentObject*> obj);
Then

into ImportOCAF.cpp replace the loop with a single call

Code: Select all

        // localValue contain the object that I must add to
        // the local Part
        // I must add the PartOrigin and the Part itself
        pcPart->addObjects(localValue);
/*        for(int unsigned i=0;i<localValue.size();i++){
                pcPart->addObject(localValue[i]);
        }
*/
And you will get a performance boost on this loop. But there are other places which needs performance improvement. This is mostly because we need to take care about the new PartDesign.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: #619 Made TreeView stable

Post by realthunder »

vejmarie wrote:And you will get a performance boost on this loop. But there are other places which needs performance improvement. This is mostly because we need to take care about the new PartDesign.
I am sure this is going to help, but that doesn't negate the problem wmayer exposed. And I am really curious of what cause that platform difference. Too bad, Windows build take ages on my machine.

BTW, I just posted a proposal on App::Part at https://forum.freecadweb.org/viewtopic.php?f=19&t=21668. Any thoughts?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: #619 Made TreeView stable

Post by DeepSOIC »

realthunder wrote:Too bad, Windows build take ages on my machine.
Use jom.exe -j6 FreeCADGui/fast
User avatar
easyw-fc
Veteran
Posts: 3630
Joined: Thu Jul 09, 2015 9:34 am

Re: #619 Made TreeView stable

Post by easyw-fc »

realthunder wrote: And I am really curious of what cause that platform difference.
Do you have VBO enabled in both OSes?
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: #619 Made TreeView stable

Post by realthunder »

easyw-fc wrote:
realthunder wrote: And I am really curious of what cause that platform difference.
Do you have VBO enabled in both OSes?
How to check?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: #619 Made TreeView stable

Post by realthunder »

DeepSOIC wrote:Use jom.exe -j6 FreeCADGui/fast
Jom official download server is down. What are the odds of that! Care to post the binarry here? BTW, I am having trouble with Windows debug build. I am getting a bunch of unfound reference when linking OCC. Release build is fine. Any tricks on that?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: #619 Made TreeView stable

Post by wmayer »

realthunder wrote:
vejmarie wrote:And you will get a performance boost on this loop. But there are other places which needs performance improvement. This is mostly because we need to take care about the new PartDesign.
I am sure this is going to help, but that doesn't negate the problem wmayer exposed. And I am really curious of what cause that platform difference. Too bad, Windows build take ages on my machine.
That's exactly point. And I just want to point out again that I reverted the recent changes on Tree.cpp/h so that it was at the state of a month ago and doing so the load was again very fast, i.e. 30 sec. This also means that the use of App::Part only has a minimal impact on this issue. But nevertheless it makes sense to have the addObjects method to avoid too many update cycles.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: #619 Made TreeView stable

Post by DeepSOIC »

realthunder wrote:Jom official download server is down. What are the odds of that! Care to post the binarry here?
You can use nmake similarly. For single file compile, nmake gives better speed on my machine. But for more than one (e.g. when a header is changed), jom is better.
I can send you jom.exe, but I'm not sure if it will work stand-alone.

EDIT: sent in PM
User avatar
vejmarie
Posts: 713
Joined: Mon Jan 04, 2016 4:52 pm
Location: Somewhere between France, USA and Taiwan
Contact:

Re: #619 Made TreeView stable

Post by vejmarie »

realthunder wrote:
easyw-fc wrote:
realthunder wrote: And I am really curious of what cause that platform difference.
Do you have VBO enabled in both OSes?
How to check?
This is in global preferences -> Display, but this shouldn't had any impact on the Tree, as this is for Rendering, and still under dev.
Post Reply