I must say I agree with the other two "pro-subform" opinions, but can add some
perspective about "why".
All design documents are just that. Documents. Any subform called involves
finding a document by its NoteID and opening it. This is all done in C and is
quite fast. If the contents of the subform are almost entirely passthrough
text, there is very little processing that goes on after the subform loads.
What can kill performance is having many subforms that do calculations,
rendering to HTML, etc.
Also, as mentioned, dblookups can kill performance as well. You might consider
keeping these kinds of settings in a small set of documents and using a shared
field populated with their UniqueID's or something. There are further steps to
make this a maintenance-free option, but avoiding dblookups, columns, etc. is
always a good idea. Fast is good. Faster is better! :-)
I must say I agree with the other two "pro-subform" opinions, but can add some perspective about "why".
All design documents are just that. Documents. Any subform called involves finding a document by its NoteID and opening it. This is all done in C and is quite fast. If the contents of the subform are almost entirely passthrough text, there is very little processing that goes on after the subform loads. What can kill performance is having many subforms that do calculations, rendering to HTML, etc.
Also, as mentioned, dblookups can kill performance as well. You might consider keeping these kinds of settings in a small set of documents and using a shared field populated with their UniqueID's or something. There are further steps to make this a maintenance-free option, but avoiding dblookups, columns, etc. is always a good idea. Fast is good. Faster is better! :-)