У меня возникли проблемы со скоростью передачи данных.В этом конкретном случае я использую его в качестве держателя данных, он никогда не используется в графическом интерфейсе или любом другом сценарии, который фактически использует какие-либо изящные функции.
В моей скоростной трассировке этот конкретный конструктор показывался как интенсивный пользователь времени, когда в моей базе данных ~ 40 тыс. Строк.Основным пользователем был set_Item из DataTable.
protected myclass(DataTable dataTable, DataColumn idColumn)
{
this.dataTable = dataTable;
IdColumn = idColumn ?? this.dataTable.Columns.Add(string.Format("SYS_{0}_SYS", Guid.NewGuid()), Type.GetType("System.Int32"));
JobIdColumn = this.dataTable.Columns.Add(string.Format("SYS_{0}_SYS", Guid.NewGuid()), Type.GetType("System.Int32"));
IsNewColumn = this.dataTable.Columns.Add(string.Format("SYS_{0}_SYS", Guid.NewGuid()), Type.GetType("System.Int32"));
int id = 1;
foreach (DataRow r in this.dataTable.Rows)
{
r[JobIdColumn] = id++;
r[IsNewColumn] = (r[IdColumn] == null || r[IdColumn].ToString() == string.Empty) ? 1 : 0;
}
Копая глубже в трассировке, выясняется, что set_Item вызывает EndEdit, что наводит мои мысли на поддержку транзакций в DataTable, для которого я не используюв моем сценарии.
Таким образом, я решил открыть редактирование всех строк и никогда больше не закрывать их.
_dt.BeginLoadData();
foreach (DataRow row in _dt.Rows)
row.BeginEdit();
Есть ли лучшее решение?Это слишком похоже на большой гигантский хак, который в конечном итоге придет и укусит меня.
Вы можете предположить, что я вообще не использую DataTable, но я уже учел это и отклонил его из-за количества усилий, которыебудет необходимо переопределить с пользовательским классом.Основная причина, по которой он является датируемым, заключается в том, что это древний код (время .net 1.1), и я не хочу тратить столько времени на его изменение, а также потому, что исходная таблица получается из стороннего компонента.
Данные трассировки из тестовой установки (обратите внимание, что прослушивателей событий НЕТ вообще):
Без открытия Редактировать 100k строк (и 9 столбцов):
RaiseRowChanging (30.68%) 1204 msec 100k calls
- get_Item (6.54%) 277msec 900k calls
- UpdatingCurrent (3.09%) 130msec 900k calls
С открытием Редактировать 100kстроки (и 9 столбцов):
RaiseRowChanging (3.68%) 98 msec 100k calls
- ...