Вы всегда можете проверить это самостоятельно и посмотреть ... но, да, это немного более эффективным. Или это был последний раз, когда я его тестировал. Причина в том, что компилятор объединяет операторы, а полученный r-код немного меньше.
Но эффективность почти всегда является плохой причиной для этого. Сохранение микросекунды здесь и там бледнеет рядом с тем, чтобы избегать дискового ввода-вывода или выбора более эффективного алгоритма. Хорошие причины:
0) В темные века существовал предел в 63k r-кода для каждой программы. Это был способ уменьшить размер r-кода и оставаться под этим ограничением (хорошо, это может быть не «хорошая» причина). Еще один способ помочь вам в том, что вы также можете часто избегать пары DO ... END и дополнительно уменьшать размер r-кода.
1) При создании записи поля, которые являются частью индекса, будут возвращены в базу данных по мере их назначения (а не в конце транзакции). Объединение всех назначений в один оператор помогает избежать несовместимые грязные чтения. (Это, вероятно, лучшая причина для этого.)
2) Читаемость - вы можете утверждать, что группировка последовательных заданий более четко показывает ваше намерение и, следовательно, более читаема. (Мне нравится эта причина, но не все согласны.)
Это имеет смысл для назначений базы данных, но как насчет загрузки переменных в программу? В этом случае он более эффективен? – Bill
Да, он более эффективен. Это связано с тем, как Progress обрабатывает доступ к памяти. – ilovebigmacs