I am writing a performance sensitive software layer in C++ on the top of FGDB C++ API VS2010 version 1.3 to read FGDB data. I have some basic doubts about iterating through rows over table in FGDB:
As I understand FileGDBAPI::EnumRows is a forward only enumerator. My requirement is to move backwards either to previous record or to first record. To achieve this I am constructing a new EnumRows instance using Geodatabase::ExecuteSQL() or Table::Search() and calling Next() one time less than the current row number to get to that record. How costly is creating a new enumerator using Table::Search method everytime when my client wants to move to previous or first record?
How costly is the EnumRows::Next(Row& row) call? Since with every call it fills the Row reference, does it internally just moves the pointer over underlying cached buffer and Row fetches the field values data lazily when asked by the client using Row reference? If Row is filled with field values eagerly in every Next() call, then it might be very costly method to call frequently when actually we do not want to fetch values of each record.
Another approach I could think of is to move to a certain record in backward direction is to cache the "ObjectID" and then call Table::Search() method to query for that ObjectID. Is ObjectID field indexed in FileGeodatabase to make search fast? Will "ObjectID" field be present in all FileGeodatabase data, can there be any case where it is not present or its name is different?
Is there any efficient method to GetRowCount() on an EnumRows instance resulted from Table::Search() or Geodatabase::ExecuteSQL() call? If there is no envelop applied and no filter applied, Table::GetRowCount() should be faster, but in majority of cases we work on EnumRows instance where it could be a filtered data.
This Forum isn't so busy that you can't find posts on at least some of these topics, but it's likely you'll need to experiment with the majority of these optimization details within your own app (e..g., your own memory management needs will impact the efficiency of caching).
You can always determine the rowid column by FieldType (.fieldTypeOID). OIDs are indexed, unique, and NOT NULL.
