Casual observation of log files seem to indicate setting document properties is taking time. For example for 30k of EDI documents I have seen 3 minutes.

The time may vary with the size of the individual documents and also collectively. These numbers have to be seen.

If the process is long with with many sub processes and hundreds of shapes the number of set properties could add up.

set properties could also be wrongly used where most of the connectors are poring the data into set properties as opposed to connector calls and then merging the data back with the main document in to an enhanced profile with more fields. I suspect this is a better approach instead of relying on set properties. connector calls seem to be significantly faster than calling out of a set properties or a map.

1. Call outs from set properties to connectors appears to be less efficient. How much less? I am not sure of the numbers.

2. If there is only one field to be added, may be having a map and a document cache might be an overkill

3. if there are 5 fields from an sql that need to be added, it may be better to have the connector call the fields and map them back. Possibly you may have to call that SQL 5 times to set fields individually. May be there is a way to spray the fields from a single SQL call as multiple document properties (I don't think so!)

4. Even at times having the set properties pull the multiple values from a doc cache and set them as document properties

Some times developers are using sub processes to provide common logic based on document properties solely and not the document itself.

Such an approach is misleading in my opinion. Better way is to define an explicit data structure (profile) that the sub process knows and declares that it can handle and have the caller process map to the needed profile to achieve that.

This could possibly avoid carrying large documents across a sub process if they don't have to be.

It is expensive to carry thousands of large size documents across shapes and sub processes. This at much is clear.

So if you were using set properties and relying on the set properties to get your job done you are unnecessarily carrying the large documents through when you are depending meta data like the set properties to do your work.

One option is to create a smaller profile and move your properties into that smaller profile and move that smaller document set across.

There is one case where set properties might make sense, where you have to set one or two fields and using a map instead might make the process take longer as that takes copying a large document field by field to the new document format.

Carry your work with a least size set of documents if you can. Don't let a very large size documents carry your properties when the documents themselves are not used!

if the documents are large mapping them with a new field by repeating the rest of the fields could be time consuming.

In such cases adding one or more fields through document properties might leave the document intact and add the fields on top.

There may be a compromise.

Even here, if the number of properties increase, you may want to consider doing through a connector and use a doccache to pull the property values.