Kevin Martin 41f09db9e1 Address performance of existing unique-name generation (Part 2) (#18676)
As described in Issue 16849, the existing Tools::getUniqueName method
requires calling code to form a vector of existing names to be avoided.

This leads to poor performance both in the O(n) cost of building such a
vector and also getUniqueName's O(n) algorithm for actually generating
the unique name (where 'n' is the number of pre-existing names).

This has  particularly noticeable cost in documents with large numbers
of DocumentObjects because generating both Names and Labels for each new
object incurs this cost. During an operation such as importing this
results in an O(n^2) time spent generating names.

The other major cost is in the saving of the temporary backup file,
which uses name generation for the "files" embedded in the Zip file.
Documents can easily need several such "files" for each object in the
document.

This update includes the following changes to use the newly-added
UniqueNameManager as a replacement for the old Tools::getUniqueName
method and deletes the latter to remove any temptation to use it as
its usage model breeds inefficiency:

Eliminate Tools::getUniqueName, its local functions, and its unit tests.

Make DocumentObject naming use the new UniqueNameManager class.

Make DocumentObject Label naming use the new UniqueNameManager class.
This needs to monitor DocumentObject Labels for changes since this
property is not read-only. The special handling for the Label
property, which includes optionally forcing uniqueness and updating
links in referencing objects, has been mostly moved from
PropertyString to DocumentObject.

Add Document::containsObject(DocumentObject*) for a definitive
test of an object being in a Document. This is needed because
DocumentObjects can be in a sort of limbo (e.g. when they are in the
Undo/Redo lists) where they have a parent linkage to the Document but
should not participate in Label collision checks.

Rename Document.getStandardObjectName to getStandardObjectLabel
to better represent what it does.

Use new UniqueNameManager for Writer internal filenames within the zip
file.

Eliminate unneeded Reader::FileNames collection. The file names
already exist in the FileList collection elements. The only existing
use for the FileNames collection was to determine if there were any
files at all, and with FileList and FileNames being parallel
vectors, they both had the same length so FileList could be used
for this test..

Use UniqueNameManager for document names and labels. This uses ad hoc
UniqueNameManager objects created on the spot on the assumption that
document creation is relatively rare and there are few documents, so
although the cost is O(n), n itself is small.

Use an ad hoc UniqueNameManager to name new DymanicProperty entries.
This is only done if a property of the proposed name already exists,
since such a check is more-or-less O(log(n)), almost never finds a
collision, and avoids the O(n) building of the UniqueNameManager.
If there is a collision an ad-hoc UniqueNameManager is built
and discarded after use.
The property management classes have a bit of a mess of methods
including several to populate various collection types with all
existing properties. Rather than introducing yet another such
collection-specific method to fill a UniqueNameManager, a
visitProperties method was added which calls a passed function for
each property. The existing code (e.g. getPropertyMap) would be
simpler if they all used this but the cost of calling a lambda
for each property must be considered. It would clarify the semantics
of these methods, which have a bit of variance in which properties
populate the passed collection, e.g. when there are duplicate names..
Ideally the PropertyContainer class would keep a central directory of
all properties ("static", Dynamic, and exposed by ExtensionContainer and
other derivations) and a permanent UniqueNameManager. However the
Property management is a bit of a mess making such a change a project
unto itself.
2025-02-24 10:23:53 -06:00
2025-02-22 17:37:24 +01:00
2023-02-13 15:46:28 +01:00
2025-02-17 10:17:32 -06:00
2024-07-14 09:24:22 +02:00
2025-01-06 14:34:17 -03:00
2025-01-21 09:50:43 -06:00
2025-02-21 08:06:16 +01:00
---
2024-05-27 10:57:45 -05:00

Your own 3D parametric modeler

WebsiteDocumentationForumBug trackerGit repositoryBlog

Release Crowdin Liberapay

Overview

  • Freedom to build what you want FreeCAD is an open-source parametric 3D modeler made primarily to design real-life objects of any size. Parametric modeling allows you to easily modify your design by going back into your model history to change its parameters.

  • Create 3D from 2D and back FreeCAD lets you to sketch geometry constrained 2D shapes and use them as a base to build other objects. It contains many components to adjust dimensions or extract design details from 3D models to create high quality production-ready drawings.

  • Designed for your needs FreeCAD is designed to fit a wide range of uses including product design, mechanical engineering and architecture, whether you are a hobbyist, programmer, experienced CAD user, student or teacher.

  • Cross platform FreeCAD runs on Windows, macOS and Linux operating systems.

  • Underlying technology

    • OpenCASCADE A powerful geometry kernel, the most important component of FreeCAD
    • Coin3D library Open Inventor-compliant 3D scene representation model
    • Python FreeCAD offers a broad Python API
    • Qt Graphical user interface built with Qt

Installing

Precompiled packages for stable releases are available for Windows, macOS and Linux on the Releases page.

On most Linux distributions, FreeCAD is also directly installable from the software center application.

For development releases visit the weekly-builds page.

Other options are described on the wiki Download page.

Compiling

FreeCAD requires several dependencies to correctly compile for development and production builds. The following pages contain updated build instructions for their respective platforms:

Reporting Issues

To report an issue please:

  • Consider posting to the Forum, Discord channel, or Reddit to verify the issue;
  • Search the existing issues for potential duplicates;
  • Use the most updated stable or development versions of FreeCAD;
  • Post version info from Help > About FreeCAD > Copy to clipboard;
  • Restart FreeCAD in safe mode Help > Restart in safe mode and try to reproduce the issue again. If the issue is resolved it can be fixed by deleting the FreeCAD config files.
  • Start recording a macro Macro > Macro recording... and repeat all steps. Stop recording after the issue occurs and upload the saved macro or copy the macro code in the issue;
  • Post a Step-By-Step explanation on how to recreate the issue;
  • Upload an example file (FCStd as ZIP file) to demonstrate the problem;

For more details see:

Note

The FPA offers developers the opportunity to apply for a grant to work on projects of their choosing. Check jobs and funding to know more.

Usage & Getting Help

The FreeCAD wiki contains documentation on general FreeCAD usage, Python scripting, and development. View these pages for more information:

The FreeCAD forum is a great place to find help and solve specific problems when learning to use FreeCAD.


This project receives generous infrastructure support from and KiCad Services Corp.

Description
No description provided
Readme LGPL-2.1 7.9 GiB
2026-02-27 16:25:02 +00:00
Languages
C++ 51.5%
Python 45.8%
C 1.3%
CMake 0.8%
NSIS 0.2%
Other 0.2%