RecordCount против оценки BOF / EOF

Question

Я поддерживаю набор кода, который имеет класс-оболочку для SqlDataAdapter для загрузки System.Data.DataTable. Он имеет универсальную функцию, чтобы определить, имеет ли DataTable «hasRecords». Я знаю, что это небольшая проблема, но из любопытства ... Какой метод быстрее использовать?

Существующий:

    Public ReadOnly Property hasRecords() As Boolean
        Get
            hasRecords = CBool((CBool(BOF = True) And CBool(EOF = True)) = False)
        End Get
    End Property

или Возможное новое:

    Public ReadOnly Property hasRecords() As Boolean
        Get
            hasRecords = IIf(RecordCount > 0, True, False)
        End Get
    End Property

Если RecordCount определен как фиксированное значение в качестве свойства набора записей, я думаю, что подсчет будет более быстрым, поскольку один метод eval против метода множественного преобразования / eval BOF / EOF, который он использует.

Есть ли какая-либо другая причина не менять это?

Answer 1

Это кажется ненужной и потенциально рискованной оптимизацией; RecordCount может быть не всегда доступен (см. Документацию ), в то время как BOF и EOF всегда должны возвращать соответствующие ответы. Таким образом, ваша оптимизация потенциально нарушает поведение, в то же время, вероятно, обеспечивая лишь минимальный возврат производительности (который, если вы действительно заинтересованы, вам следует протестировать).

Answer 2

С точки зрения арифметики

hasRecords = Not(BOF AndAlso EOF)

против

hasRecords = (RecordCount > 0)

может показаться, что тест RecordCount может потребовать меньше усилий.Однако это было бы наивным выводом.Вам нужно будет самому выбрать время, чтобы увидеть, есть ли какая-то разница.Мое смелое предположение: в современных современных процессорах - с помощью конвейерной обработки, прогнозирования ветвлений и других передовых методов - вероятно, не будет существенной разницы.

---

Кстати, хотя вам, вероятно, будет хорошо с RecordCount, яМы обнаружили, что BOF / EOF более переносимы.Просто говорю.