SqlDataAdapter. Медленный метод заполнения
попробуйте следующее
from statistics import stdev
import statistics
class deviation(MRJob):
def mapper(self, __, line):
for num in line.split(','):
yield None, int(num)
def reducer(self, __, numbr):
yield "deviation",statistics.stdev(numbr)
if __name__ == '__main__':
deviation.run()
4 ответа
Во-первых, удостоверьтесь, что Вы представляете производительность правильно. Например, выполните запрос дважды с ADO.NET и посмотрите, намного ли второй раз быстрее, чем первый раз. Это удаляет издержки ожидания приложения для компиляции и инфраструктура отладки, чтобы расти.
Затем, проверяют настройки по умолчанию в ADO.NET и SSMS. Например, при выполнении ВЫДЕЛЕННОГО ARITHABORT в SSMS Вы могли бы найти, что он теперь работает как медленный как тогда, когда с помощью ADO.NET.
то, Что я нашел однажды, было то, которые ОТПРАВЛЯЮТСЯ, ARITHABORT в SSMS заставил сохраненный proc быть перекомпилированным и/или другая статистика, которая будет использоваться. И внезапно и SSMS и ADO.NET сообщали примерно о том же времени выполнения.
Для проверки этого посмотрите на планы выполнения относительно каждого выполнения, конкретно syscacheobjects таблица. Они будут, вероятно, отличаться.
Выполнение 'sp_recompile' на определенной хранимой процедуре отбросит связанный план выполнения от кэша, который затем дает SQL Server шанс создать возможно более соответствующий план при следующем осуществлении процедуры.
Наконец, можно попробовать" уничтожение это с орбиты " подход вычищения всего кэша процедур и буферов памяти с помощью SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Выполнение поэтому перед тестированием запроса, предотвращает использование кэшируемых планов выполнения и предыдущего кэша результатов.
Вот то, что я закончил тем, что делал:
я выполнил следующий SQL-оператор для восстановления индексов на всех таблицах в базе данных:
EXEC <databasename>..sp_MSforeachtable @command1='DBCC DBREINDEX (''*'')', @replacechar='*'
-- Replace <databasename> with the name of your database
, Если я хотел видеть то же поведение в SSMS, я выполнил proc как это:
SET ARITHABORT OFF
EXEC [dbo].[web_GetMyStuffFool] @UserID=1
SET ARITHABORT ON
Другой способ обойти это состоит в том, чтобы добавить это к Вашему коду:
MyConnection.Execute "SET ARITHABORT ON"
Для почему бы не создания этого DataReader вместо DataAdapter похоже, что у Вас есть единственный набор результатов и если Вы не собираетесь быть продвижением, возвращается в DB, и не нуждаются в ограничениях, примененных в коде.NET, Вы не должны использовать Адаптер.
РЕДАКТИРОВАНИЕ:
при необходимости в нем, чтобы быть DataTable, можно все еще вытянуть данные из DB через DataReader, и затем в.NET код использует DataReader для заполнения DataTable. Это должно все еще быть быстрее, чем доверие DataSet и DataAdapter
Я не знаю, "Почему" это настолько медленно по сути - но как Marcus указывает - сравнение Studio менеджмента к заполнению набора данных является яблоками к апельсинам. Наборы данных содержат МНОГО издержек. Я ненавижу их и НИКОГДА не использую их, если я могу помочь ему.
у Вас могут быть проблемы с несоответствиями старых версий стека SQL, или некоторые такой (особенно, учитывая Вас, очевидно, застревают в.NET 1.1 также), Платформа, вероятно, пытается сделать базу данных equivilant "Отражения" для выведения схемы и т.д. и т.д. и т.д.
Одна вещь полагать, что попытка с неудачным ограничением состоит в том, чтобы получить доступ к базе данных с datareader и создать собственный набор данных в коде. Необходимо смочь найти образцы легко через Google.