#619 Made TreeView stable
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: #619 Made TreeView stable
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.
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.
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: #619 Made TreeView stable
Add this code to GroupExtension.cppwmayer 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); }
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);
}
}
Code: Select all
virtual void addObjects(std::vector<App::DocumentObject*> obj);
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]);
}
*/
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: #619 Made TreeView stable
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.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.
BTW, I just posted a proposal on App::Part at https://forum.freecadweb.org/viewtopic.php?f=19&t=21668. Any thoughts?
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: #619 Made TreeView stable
Use jom.exe -j6 FreeCADGui/fastrealthunder wrote:Too bad, Windows build take ages on my machine.
Re: #619 Made TreeView stable
Do you have VBO enabled in both OSes?realthunder wrote: And I am really curious of what cause that platform difference.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: #619 Made TreeView stable
How to check?easyw-fc wrote:Do you have VBO enabled in both OSes?realthunder wrote: And I am really curious of what cause that platform difference.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: #619 Made TreeView stable
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?DeepSOIC wrote:Use jom.exe -j6 FreeCADGui/fast
Re: #619 Made TreeView stable
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.realthunder wrote: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.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.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: #619 Made TreeView stable
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.realthunder wrote:Jom official download server is down. What are the odds of that! Care to post the binarry here?
I can send you jom.exe, but I'm not sure if it will work stand-alone.
EDIT: sent in PM
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: #619 Made TreeView stable
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.realthunder wrote:How to check?easyw-fc wrote:Do you have VBO enabled in both OSes?realthunder wrote: And I am really curious of what cause that platform difference.