Retrieving Entity Data

Another case of potential code + performance optimisation is given with entity data retrieval.

	(cdr (assoc code (entget ename)))	(entget) retrieves all entity definition data, based on a DxfOut-like operation which creates C/C++ resbuf lists, which is then converted into a Lisp list; so both stages process a lot of loop code with data transformation, and memory allocation + deallocation, which are all heavy operations - only to get 1 or 2 definition items
	(vla-get-layer <entity> ...)	in majority of cases, the COM-based entity modification provides by far the best performance at all; AutoCAD : the (vla-get) function is also faster here BricsCAD: as BricsCAD COM is faster by factor 3...4 in generally, the (vla-get-<Property> functions are always significantly faster than any other method

Some background :
Same as with entity modification via (entmod) - it creates an assoc list, which the Lisp engine needs to transform from C/C++ resbuf list, which is generated by a DxfOut-like operation; both stages are heavy operations with lots of temporary memory needed..
On the opposite, the COM based (vla-get-<Property>) functions directly reads the desired property from the target entity, without large list data generation, conversion and parsing; the only overhead is caused by data conversion from COM data type to Lisp data type for the result value, also the memory usage is at minimum.

BricsCAD-specific :
The "Fast-COM" mode is already implemented for a large number of properties, so (vla-get-<Property>) is the highly recommended way here; the overhead is reduced to minimum, and performance of (vla-get<Property>) functions is very close to C/C++ code (like BRX and ARX); in other words, the performance advantage to classical (cdr (assoc (entget))) is about factor 10 ... 30 (and even more).

Suggestion : as all major CAD systems meanwhile support the (vla-) function family, it is safe to adjust Lisp code to use the (vla-get-<Property>) function family - the performance gain is really significant; as all the vla/vlax/vlr functions become available for Linux/Mac as well, there is no risk for portability.

If Lisp code needs to remain with (entget) :
Even in this case the BricsCAD Lisp engine provides a high-performance alternative for (entget) - the VLE function library offers (vle-entget) and (vle-entget-m) functions, which directly return the required entity data for a given DXF group code (or a list of DXF group code);
for a large range of DXF group code, the BricsCAD Lisp engine does not internally generate the C/C++ resbuf list, but directly queries the related entity data - only for entity-specific DXF codes, the Lisp engine uses that C/C++ resbuf list internally, withotu conversion into a Lisp list;
as a smart advantage, these VLE functions also return "default" values which are otherwise omitted in (entget) list, like color, lineweight, linetype etc., which simplifies Lisp code design;
all VLE functions are also available under AutoCAD and other CAD software by emulation with vle-extension.lsp, so there is no compatibility problem with using VLE library functions (please see compatibility notes).