|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR®Dima TЭто все обертки над BULK INSERT , который можно вызывать откуда угодно. Правильно. Весь вопрос в том, как удобно её вызвать, когда, например, есть массив из нескольких миллионов записей. Сохранить в файл, а потом звать bcp.exe? Тогда программа становится не самодостаточной, кроме того, bcp.exe - тоже не самодостаточна и хочет видеть нескольких dll из состава SQL сервера. Класть файл на сервер (а потом звать в запросе BULK INSERT) тоже далеко не всегда возможно. bcp.exe просто посылает команду BULK INSERT, можешь сам ее послать через ADO.NET Код: c# 1. 2.
Если положить файл на сервер проблема, то с INSERT BULK поразбирайся 20514170 Но тут видится совсем другая проблема: надо ли эти миллионы записей загонять в БД? Может достаточно сохранить в файл? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2017, 12:24 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Dima Tнадо ли эти миллионы записей загонять в БД? Может достаточно сохранить в файл? Надо :) Для использования другим пользователями БД. Вести с полей такие: Код: c# 1. 2. 3. 4. 5. 6. 7. 8.
упало на 8 млн записей, хотя на маленьких кол-вах работает "на ура". ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2017, 17:17 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Алексей Кmikronпропущено... Выводы нижно делать правилные: Даже код для time-critical приложений можно писать на С#. Суть в том что промежуточный байткод может быть оттранслирован в оптималный машинный код для конкретного процессора. С нативным машинным кодом такого фокуса уже не получится. Читать Затраты на поддержку безопасного кода в .Net таки дают о себе знать. Даже если проверка границ массивов где-то и выносится на этап компиляции, то далеко не везде. Не думаю, что компиляция под конкретный процессор может компенсировать эти затраты. не надо путать холодное с мягким компиляцию под конкретную платформу можно использовать и для С кода, например используя байт-код LLVM или напрямую указывая компилятору оптимизацию под определённую платформу автосборку мусора и проверку выходов за границу массивов можно сделать и в нативном языке это совершенно не связанные вещи ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 08:19 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR®Вести с полей такие: Код: c# 1. 2. 3. 4. 5. 6. 7. 8.
упало на 8 млн записей, хотя на маленьких кол-вах работает "на ура". Как именно упало? Сказало "нихачу больше работать", и закрылось? P.S. для миллионных объемов записей есть перегрузки SqlBulkCopy.WriteToServer, принимающие на вход DbDataReader/IDbDataReader. Чтобы не закачивать предварительно все эти миллионы записей на клиента, а отдавать на запись по мере получения. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 08:46 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
kealon(Ruslan)Алексей Кпропущено... Затраты на поддержку безопасного кода в .Net таки дают о себе знать. Даже если проверка границ массивов где-то и выносится на этап компиляции, то далеко не везде. Не думаю, что компиляция под конкретный процессор может компенсировать эти затраты. не надо путать холодное с мягким компиляцию под конкретную платформу можно использовать и для С кода, например используя байт-код LLVM или напрямую указывая компилятору оптимизацию под определённую платформу автосборку мусора и проверку выходов за границу массивов можно сделать и в нативном языке это совершенно не связанные вещи Хороший пример LLVM, показывает преимущества промежуточного byte-code. Сегодня x86 завтра ARM и везде оптимально выполняется в рамках платформы/ОС. Таким образом MSIL не является чем то ограничивающим. Проверки границ массивов: Да, они стоят время. Но теоретически, что мешает их полностью уничтожит во времена выполнения? майкрософт надеюсь (скоро) поймёт что встраивать меры защиты в среду выполнения - напрасная затея: только вредит распространению платформы и не увеличивает безопасность системы. ИМХО Безопасность системы должна и может гарантировать только сама система. Тогда можно ожидать и появления необходимых ключей/switches для JIT и сравнимую производительность. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 10:11 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
mikronПроверки границ массивов: Да, они стоят время. Но теоретически, что мешает их полностью уничтожит во времена выполнения? Кое-какие шаги МС сделал в этом направлении 20504475 Полностью не уничтожить, например если индекс как-то рассчитывается, то контроль нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 10:22 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Dima TПолностью не уничтожить, например если индекс как-то рассчитывается, то контроль нужен. Почему нужен? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 10:47 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Сон Веры ПавловныКак именно упало? Сказало "нихачу больше работать", и закрылось? Примерно так. :) Текст сообщения приведён в коде выше. Из-за нехватки времени не анализировал exception. Использовал перегрузки SqlBulkCopy.WriteToServer(DataTable) и SqlBulkCopy.WriteToServer(DataRow[]) - результаты близки. 6 млн. записей проходит, пришлось писать разбивку на куски. Сон Веры ПавловныЧтобы не закачивать предварительно все эти миллионы записей на клиента, а отдавать на запись по мере получения. Они у меня образуются на клиенте, ничего закачивать не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 11:42 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR®Они у меня образуются на клиенте, ничего закачивать не надо. Имплементируйте свой IDataReader, и отдавайте по мере образования, и будет вам щастье. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 11:49 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Сон Веры ПавловныИмплементируйте свой IDataReader, и отдавайте по мере образования, и будет вам щастье. Чем это будет лучше использования запроса в стиле IF NOT EXIST... INSERT... VALUES... ? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 12:33 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR® в стиле IF NOT EXIST... INSERT... VALUES... ? С этого места поподробней: Сколько записей в таблице? сколько реально вставляется из 8 млн.? Как вариант: можно IF NOT EXIST проверять до отправки в БД, т.е. залить таблицу в Dictionary и там проверять, если нет, то INSERT. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 13:13 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
mikronDima TПолностью не уничтожить, например если индекс как-то рассчитывается, то контроль нужен. Почему нужен? Я собственно про вот это JitSkipArrayBoundCheck ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 14:45 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Dima TAR® в стиле IF NOT EXIST... INSERT... VALUES... ? С этого места поподробней: Сколько записей в таблице? сколько реально вставляется из 8 млн.? Сейчас 49 млн. Текущий этап работы даст ещё ~69 млн.(из которых было сделано 8 на момент начала экспериментов с SqlBulkCopy.WriteToServer() ) Так говорит наука математика. :) До открытия мной (разумеется, для себя) SqlBulkCopy в .Net я рисовал IF NOT EXISTS... INSERT... VALUES... по ~тысяче записей за батч и запускал на выполнение. Теперь просто придётся перед нажатием кнопки сохранения проверить, что не будет нарушения PK таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 15:17 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
mikronmikronпропущено... Почему нужен? Я собственно про вот это JitSkipArrayBoundCheck Не понял о чем там речь. Я вот о чем: адрес элемента массива вычисляется по формуле Код: c# 1.
где i индекс нужного элемента, K размер элемента в байтах. Если вдруг i окажется больше размера массива, то произойдет обращение непонятно куда, а т.к. адресное пространство линейно, то там может оказаться содержимое другого объекта. Если туда что-нибудь записать, то кривой код отработает без ошибок, а когда дойдет до использования испорченного объекта, то начнется мистика и косяк искать будет очень тяжело. ИМХО от этого никак не защититься, кроме как предварительной проверкой индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 15:17 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Кстати, 2 копейки про надёжность C#, а точнее - про разочарование в ней. Код: c# 1.
Что произойдёт, если Max == 2147483647 == Int32.MaxValue ? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 15:39 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Dima Tmikronпропущено... Я собственно про вот это JitSkipArrayBoundCheck Не понял о чем там речь. Я вот о чем: адрес элемента массива вычисляется по формуле Код: c# 1.
где i индекс нужного элемента, K размер элемента в байтах. Если вдруг i окажется больше размера массива, то произойдет обращение непонятно куда, а т.к. адресное пространство линейно, то там может оказаться содержимое другого объекта. Если туда что-нибудь записать, то кривой код отработает без ошибок, а когда дойдет до использования испорченного объекта, то начнется мистика и косяк искать будет очень тяжело. ИМХО от этого никак не защититься, кроме как предварительной проверкой индекса. Это вроде как общеизвестно. Я о чем: мы сравниваем скорость MSIL с native code. Много факторов влияет на результат сравнения, но два фундаментальных для .Net CLR: JIT и Boundary checks. JIT - иногда сильно помогает, редко - ограничивает (oсобенно заметно для короткоживущих приложений), но не для приведённых тестов. Boundary checks - ограничивают и влияют на приведенные тесты, но могут быть удалены/выключены для CLR. Ссылку я привел. Вот если их выключит то можно сравнивать native code vs. MSIL на более равных условиях. Твоё утверждение, что их (boundary checks) нельзя убрать и контроль границ нужен я не понял. Почему ты так считаеш? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 16:28 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR®Кстати, 2 копейки про надёжность C#, а точнее - про разочарование в ней. Код: c# 1.
Что произойдёт, если Max == 2147483647 == Int32.MaxValue ? А так? Код: c# 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 16:30 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
mikronА так? Можно и так, но на все циклы checked'ов не напасёшься. Получилось неприятно, т.к. цикл был долгий сам по себе, и было не очевидно, что произошло зацикливание. Да и брать в checked{}, получается, надо всё тело цикла, а в нём много всего, что проверять не требуется. В результате опять будет не лучшее время. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 16:52 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
AR®mikronА так? Можно и так, но на все циклы checked'ов не напасёшься. Получилось неприятно, т.к. цикл был долгий сам по себе, и было не очевидно, что произошло зацикливание. Да и брать в checked{}, получается, надо всё тело цикла, а в нём много всего, что проверять не требуется. В результате опять будет не лучшее время. Да просто лень, да? Код: c# 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 16:59 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
Уже сам догадался. :) Так, пожалуй, можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 17:02 |
|
Максимальный размер ConcurrentDictionary в 32-битных приложениях
|
|||
---|---|---|---|
#18+
mikronТвоё утверждение, что их (boundary checks) нельзя убрать и контроль границ нужен я не понял. Почему ты так считаеш? Мое утверждение было немного о другом 20504475 Я к тому что там где можно убрать - компилятор C# сам убирает и не надо извращаться с unsafe, все уже оптимизировано, результаты того теста это подтверждают. Но есть случаи когда индекс элемента не счетчик цикла, а вычисляемое значение или полученное извне, тут его надо проверять хоть в C# хоть в С++, иначе можно получить вышеописанную проблему. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 17:04 |
|
|
start [/forum/topic.php?fid=20&msg=39463155&tid=1399876]: |
0ms |
get settings: |
12ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 283ms |
total: | 425ms |
0 / 0 |