[C++ Connect U14] Placing parametric cells takes long time

Hi

I've made some code to place parametric cells and edit the ItemType property values. I've realized that when I work with parametric cells that are just a little complex it takes quite some time.

        auto& cellHandler = ParametricCellHandler::GetInstance();
		EditElementHandle defCellEeh;
		if (ParameterStatus::Success != cellHandler.CreateCellElement(defCellEeh, *defaultInfo))
			return ERROR;

		lifalib_eehSetLvAndActiveCoWtSt(defCellEeh, levelID, false, false, false, true);

		lifalib_log("lifalib", 2, 1, "lifalib_placeParametricCellWC - Before addToModel");
		defCellEeh.AddToModel();
		lifalib_log("lifalib", 2, 1, "lifalib_placeParametricCellWC - After addToModel");
		lifalib_log("lifalib", 2, 1, "lifalib_placeParametricCellWC - Before updateItemTypes");

		std::vector<WString> params;
		std::vector<WString> values;
		if (!splitParams(strParams, strValues, params, values))
			return false;
		for (int paramIndex = 0; paramIndex < (int)params.size(); paramIndex++)
		{
			double value;
			if (swscanf(values[paramIndex].c_str(), L"%lf", &value) == 1)
				//lifalib_updateItemTypePropertyOnElm3(defCellEeh, L"LIFA", L"Rectangle", params[paramIndex].c_str(), NULL, NULL, &value, NULL);
				lifalib_updateItemTypePropertyOnElm3(defCellEeh, L"Symboler", L"Tree", params[paramIndex].c_str(), NULL, NULL, &value, NULL);
			else
				return false;
		}
		lifalib_log("lifalib", 2, 1, "lifalib_placeParametricCellWC - After updateItemTypes");

I've attached a cellibrary with 3 cells.

When I use this code with the cell "Rectangle" - (very simple) it goes quite fast - something between 2 and 3 seconds to place 10 cells.

When I use the cell "Tree" it takes about 11 seconds to place 10 cells. When I remove half of the elements in this cell (see "Tree2" the time is approx. halved.

How can that be ?

TIA, Evan

ParametricSymbols.cel

Parents
  • swscanf(values[paramIndex].c_str(), L"%lf", &value)

    You're writing C++  — try std::stod().

    When I use this code
    lifalib_updateItemTypePropertyOnElm3

    But that function is opaque to us. It's hard for the doctor to examine a patient who is absent.

     
    Regards, Jon Summers
    LA Solutions

  • The function looks like this:

    BentleyStatus lifalib_updateItemTypePropertyOnElm3(EditElementHandleR eehBaseElm, const wchar_t* pchItemTypeLibName, const wchar_t* pchItemTypeName, const wchar_t* pchPropName, bool* newValueBoolP, int* newValueIntP, double* newValueDoubleP, wchar_t* newValueString)
    {
    	CustomItemHost  itemHost(eehBaseElm, true);
    	DgnECInstancePtr hostItemData = itemHost.GetCustomItem(pchItemTypeLibName, pchItemTypeName);
    	ECValue value;
    
    	bool valueUpdated = false;
    	ECObjectsStatus rc = ECOBJECTS_STATUS_Error;
    	if (hostItemData != NULL)
    	{
    		if ((rc = hostItemData->GetValue(value, pchPropName)) == ECObjectsStatus::ECOBJECTS_STATUS_Success)
    		{
    			switch (value.GetPrimitiveType())
    			{
    			case PrimitiveType::PRIMITIVETYPE_Boolean:
    				value.SetBoolean(*newValueBoolP);
    				valueUpdated = true;
    				break;
    
    			case PrimitiveType::PRIMITIVETYPE_Integer:
    				value.SetInteger(*newValueIntP);
    				valueUpdated = true;
    				break;
    
    			case PrimitiveType::PRIMITIVETYPE_Double:
    				value.SetDouble(*newValueDoubleP);
    				valueUpdated = true;
    				break;
    
    			case PrimitiveType::PRIMITIVETYPE_String:
    				value.SetString(newValueString);
    				valueUpdated = true;
    				break;
    
    			default:
    				lifalib_dmsg("lifalib_updateItemTypePropertyOnElm - Unknown propertyType %d", value.GetPrimitiveType());
    				break;
    			}
    
    			if (valueUpdated)
    				if ((rc = hostItemData->SetValue(pchPropName, value)) == ECOBJECTS_STATUS_Success)
    					hostItemData->WriteChanges();
    		}
    	}
    
    	if (rc != ECOBJECTS_STATUS_Success)
    	{
    		wchar_t statusMessage[100];
    		lifalib_getECObjectsStatusMessage(rc, statusMessage);
    		lifalib_dmsg("Error by updating ItemType property %ls->%ls: %ls", pchItemTypeName, pchPropName, statusMessage);
    		return ERROR;
    	}
    	else
    		return SUCCESS;
    }

    Regards, Evan

  • CustomItemHost  itemHost(eehBaseElm, true);

    Functions that take an enum are self-documenting because the enum member is self-describing.  Funtions that take a bool are better written with an explicit named value...

    const bool ScheduleItems { true };
    CustomItemHost  itemHost(eehBaseElm, ScheduleItems);

    That duplicates the default CustomItemHost constructor.  Furthermore, it throws light onto this later statement...

    hostItemData->WriteChanges();

    In other words, you've instructed MicroStation to update your Item Type properties, and then you update them yourself.  Do one or the other, but not both.

     
    Regards, Jon Summers
    LA Solutions

Reply
  • CustomItemHost  itemHost(eehBaseElm, true);

    Functions that take an enum are self-documenting because the enum member is self-describing.  Funtions that take a bool are better written with an explicit named value...

    const bool ScheduleItems { true };
    CustomItemHost  itemHost(eehBaseElm, ScheduleItems);

    That duplicates the default CustomItemHost constructor.  Furthermore, it throws light onto this later statement...

    hostItemData->WriteChanges();

    In other words, you've instructed MicroStation to update your Item Type properties, and then you update them yourself.  Do one or the other, but not both.

     
    Regards, Jon Summers
    LA Solutions

Children