This page contains performance hints accessing database information through Magik.
You do not want to use db_set.add() on 1:n or 0:n joins! This method is very very (extremely) slow. Always use the reverse join field to set the relationship. This approach is at least 50x faster!
Bulk Data Manipulation
If you have a large number of features you are adding, modifying, or deleting, you may want to use !notify_database_data_changes?! and view.notify_suppressed_data_changes(). See Main Help's Application Development->Application Development Techniques->Database change notification->2 Making data changes for more details. Improves performance by at least 50%.
Also the above may fix errors relating to "mevents.c:239:Error - events queue overflow"
There are several ways to get the rwo_type from a geometry or a record.
You can get a handle to the rwo and do an rwo.rwo_type or you can do rwo.descriptor.name. The rwo_type call is nearly twice a slow as calling rwo.descriptor.name. So use rwo.descriptor.name, which also works for ds_records, for determining the record type.
For the geometry you can call geom.rwo.descriptor.name or you can use geom.rwo_type. In this case the geom.rwo_type is faster by double then the call to RWO's descriptor. So my guess is that the rwo_type on rwo actually looks for a geometry and does an rwo_type on a geometry.
On rwo_record or ds_record, you will want to use obj.descriptor.name. On a geometry use geom.rwo_type.
If you do many queries on a collection that use something other then the key field, you should consider using indexes. Indexes allow you to identify a combination of fields that is searched more often then others. The indexes are stored in the database and is used to quickly find objects matching the criteria given. There are 2 ways to create indexes. The first is through the CASE tool. The CASE Object Editor has a button that allows you to create indexes. The second way will not require a data model change. you can use add_index() on the collection.