You can use MDX2JSON or DeepSee REST API for pivot execution -> JSON conversion.

Tried it again, got the same results as you. $find performs better on both short (20 chars per piece, 100 pieces) and long strings (2000 chars per piece, 100 pieces).

Please don't remove class reference.

Graphs (and measurements in a method) include conversion times.

>$find

I tried this:

$$$START("Using $find (hardcoded delimiter): ")
For i=1:1:pIterations {
    Set tPosition = 0
    Do {
        Set tNewPosition = $Find(tString,",",tPosition)
        Set tValue = $Select(tNewPosition'=0:$Extract(tString,tPosition,tNewPosition-2),1:$Extract(tString,tPosition,*))
        Set tPosition = tNewPosition
    } While tPosition '= 0
}
$$$END

It was slow. Is there any way to write this faster - eg. without select (or other condition for the last piece)?

> Pros/Cons for multiple simple deployments vs single more complex deployment)

If you have a virtualization platform and clients are heavy users, it would probably make a lot of sense to go with multiple simple deployments, and if you'll have many clients who can't load a single smallest node then "single complex"  would be better.

Developing "lots of simple" system (so 1 simple system with multiple deploys) would be cheaper (as you don't have tyo think about domains and security would be simpler, maybe some other simplifications would be possible), but hosting would (maybe) be more expensive as there is a lot of overhead in resources (to run OS/Cache for each deploy).

What's the advantage of using $$$ERRORCODE macro? ^%qCacheObjectErrors global contains the same values.

%XML.Reader and %SQL.Import.Mgr respectively.

One approach would be to use %XML.DataSet to convert SQL results into XML:

Set result=##class(%XML.DataSet).%New()                                  
Do result.Prepare("SELECT TOP 3 ID, Name FROM Sample.Person")
Do result.Execute()                                                      1
Do result.WriteXML("root",,,,,1) 

Outputs:

<root>
<s:schema id="DefaultDataSet" xmlns="" attributeFormDefault="qualified" elementFormDefault="qualified" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
  <s:element name="DefaultDataSet" msdata:IsDataSet="true">
    <s:complexType>
      <s:choice maxOccurs="unbounded">
        <s:element name="SQL">
          <s:complexType>
            <s:sequence>
              <s:element name="ID" type="s:long" minOccurs="0" />
              <s:element name="Name" type="s:string" minOccurs="0" />
            </s:sequence>
          </s:complexType>
        </s:element>
      </s:choice>
    </s:complexType>
    <s:unique name="Constraint1" msdata:PrimaryKey="true">
      <s:selector xpath=".//SQL" />
      <s:field xpath="ID" />
    </s:unique>
  </s:element>
</s:schema>
<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
<DefaultDataSet xmlns="">
  <SQL diffgr:id="SQL1" msdata:rowOrder="0">
    <ID>96</ID>
    <Name>Adam,Wolfgang F.</Name>
  </SQL>
  <SQL diffgr:id="SQL2" msdata:rowOrder="1">
    <ID>188</ID>
    <Name>Adams,Phil H.</Name>
  </SQL>
  <SQL diffgr:id="SQL3" msdata:rowOrder="2">
    <ID>84</ID>
    <Name>Ahmed,Edward V.</Name>
  </SQL>
</DefaultDataSet>
</diffgr:diffgram>
</root>

There is also %SQL.Export.Mgr class, which does SQL export.

Since project is a collection of classes (and other items, yes, but we're talking about classes here) the  flow would be something like that:

• Get project name
• Project name to class list
• Get unit tests for class list
• Run unit tests

I'm just saying that 3rd step can have more callers (alternative routes to 3rd step if you will), for example:

• Package to class list
• Wildcard expression to class list
• Namespace to class list

I usually add my classes and system classes I often reference from my classes into the project, so they can be opened faster (without dialog).