Или оператор Try.. Catch тормозов добавляет.Этот тынц (https://sites.google.com/site/bushmansnetlaboratory/sendbox/stati/database/compare) наглядно демонстрирует, что наличие исключений в цикле может существенно влиять на скорость работы приложения.
Этот тынц наглядно демонстрирует, что наличие исключений в цикле может существенно влиять на скорость работы приложения.Убрал из алгоритма оператор Try.. Catch - все равно 8 мс читает.
Убрал из алгоритма оператор Try.. Catch - все равно 8 мс читает.На скорость влияет не "Try.. Catch", а возникающие исключения (Exceptions). Если твой код работал без "Try.. Catch", значит исключений не возникало. Я не вижу в твоём коде явного способа закрытия транзакции. Соответственно выполняется Commit, что является достаточно ресурсоёмким и, в данном случае, совершенно не нужным.
7К очень уж много я там храню лишней информации.Похоже, что да.
Или оператор Try.. Catch тормозов добавляет.Только если исключение реально возникает.
Ты не проверяешь в своём коде ни параметры на входе, ни результатыПараметры на входе Doc as Document и db As DataBase я проверяю снаружи функции
Я бы в этом коде обошелся бы совсем без транзакцииВот вот! Я тоже думаю к чему мне транзакция,
Параметры на входе Doc as Document и db As DataBase я проверяю снаружи функцииПлохой, подверженный ошибкам подход.
параметр на выходы retS тоже проверяю вне функции
Вот вот! Я тоже думаю к чему мне транзакция,Кто-то мешает переписать код без использования транзакции? Можешь заменить на эмуляцию (http://bushman-andrey.blogspot.ru/2014/09/blog-post.html), в этом случае придётся заменить в коде только одно слово.
если базу открываю для чтения с флагом OpenMode.ForRead
Я не вижу в твоём коде явного способа закрытия транзакции. Соответственно выполняется Commit, что является достаточно ресурсоёмким и, в данном случае, совершенно не нужным.Если нет Commit, то выполняется Abort, который действительно ресурсоемкий.
Плохой, подверженный ошибкам подход.А что Doc и db вернее нужно было бы проверять в теле функции!?
Если нет Commit, то выполняется Abort, который действительно ресурсоемкий.Да-Да!! Саша ты прав поставил Commit и вместо 8 мс функция сразу начала работать 1 мс, а то и меньше < 1
А что, разве это не очевидно? Текущая реализация вынуждает писать тебя код проверки каждый раз, как ты будешь использовать эту функцию. Чем больше кода, тем больше вероятность появления ошибки. Кроме того, в каких-то фрагментах ты можешь вовсе забыть выполнить эту проверку. То же самое относится и к случаям, когда твою функцию будут использовать др. программисты или программы - им каждый раз нужно будет писать код проверки. Текущая реализация функции предполагает, что программист, использующий её, должен быть знаком и с её реализацией (т.е. должен знать о том, что ему нужно дополнительно выполнять ряд проверок). Это плохой, подверженный ошибкам подход в программировании.Плохой, подверженный ошибкам подход.А что Doc и db вернее нужно было бы проверять в теле функции!?
Если нет Commit, то выполняется Abort, который действительно ресурсоемкий.Согласен. Под вечер уже плохо соображаю. :)
Нужно попробовать вообще без транзакции сделать.Чем не устроил вариант с эмуляцией? По сути - это способ "без транзакции", который в коде выглядит "как транзакция".
А что, разве это не очевидно? Текущая реализация вынуждает писать тебя код проверки каждый раз, как ты будешь использовать эту функцию. Чем больше кода, тем больше вероятность появления ошибки. Кроме того, в каких-то фрагментах ты можешь вовсе забыть выполнить эту проверку. То же самое относится и к случаям, когда твою функцию будут использовать др. программисты или программы - им каждый раз нужно будет писать код проверки. Текущая реализация функции предполагает, что программист, использующий её, должен быть знаком и с её реализацией (т.е. должен знать о том, что ему нужно дополнительно выполнять ряд проверок). Это плохой, подверженный ошибкам подход в программировании
А что, разве это не очевидно? Текущая реализация вынуждает писать тебя код проверки каждый раз, как ты будешь использовать эту функцию. Чем больше кода, тем больше вероятность появления ошибки. Кроме того, в каких-то фрагментах ты можешь вовсе забыть выполнить эту проверку. То же самое относится и к случаям, когда твою функцию будут использовать др. программисты или программы - им каждый раз нужно будет писать код проверки. Текущая реализация функции предполагает, что программист, использующий её, должен быть знаком и с её реализацией (т.е. должен знать о том, что ему нужно дополнительно выполнять ряд проверок). Это плохой, подверженный ошибкам подход в программировании
Чем не устроил вариант с эмуляцией?Ну вот я и попробую с этой эмуляцией и посмотрю может еще быстрее работать будет.
Ярослав с Наташей на дне разработчика 21 января 2016 хвалили наш форум.Я на форуме до тех пор, пока здесь работает А.Н. Ривилис и отвечает на мои вопросы. :) Если ситуация изменится, то форум станет мне не интересным (как это уже случилось с caduser.ru и dwg.ru) и я перестану его посещать. Без А.Н. рейтинг форума резко упадёт, так что дружно ратуем за то, чтобы Автодеск и впредь продолжал оплачивать работу А.Н. Ривилиса на данном ресурсе.
Это как пример, как без транзакции читать словарь[/quo
Спасибо испробую этот метод!
На первый взгляд быстро, но когда нужно прочесть 1000 таких записей получается, что пользователь должен ждать уже 8 сек.Ключевое слово здесь (когда нужно прочесть 1000 таких записей). Когда есть циклы, особенно вложенные смотри в первую очередь на циклы!