Имейте словарь , который часто используется. Я имею в виду цикл, который работает в течение нескольких дней при большой загрузке данных. Int64 приходит из двух Int32. Байт - это расстояние (количество) между этими двумя Int32 из многих очень длинных списков.
В этом цикле мне нужно сделать
- Генерация ключа
- Если ключ не существует в словаре, введите ключ и значение
- Если ключ существует, и новое значение (байт) меньше существующего значения, тогда замените существующее значение новым значением
Сейчас я использую прямую математику для генерации ключа, и я знаю, что есть более быстрый путь, но я не могу понять это. Я поставил shift как тег, так как думаю, что это то, как его оптимизировать, но я не могу понять это.
Затем, когда цикл завершится, мне нужно извлечь два Int32 из Int64, чтобы вставить данные в базу данных.
Спасибо
За комментарий, который я использую, чтобы объединить два Int32 в один Int64
Int64 BigInt;
Debug.WriteLine(Int32.MaxValue);
Int32 IntA = 0;
Int32 IntB = 1;
BigInt = ((Int64)IntA * Int32.MaxValue) + IntB;
Debug.WriteLine(BigInt.ToString());
IntA = 1;
IntB = 0;
BigInt = ((Int64)IntA * Int32.MaxValue) + IntB;
Debug.WriteLine(BigInt.ToString());
IntA = 1;
IntB = 1;
BigInt = ((Int64)IntA * Int32.MaxValue) + IntB;
Debug.WriteLine(BigInt.ToString());
И лучшим ключом может быть не Int64. У меня есть два Int32, которые вместе образуют ключ. И значение байта. Мне нужен быстрый поиск этого составного ключа. Словарь работает быстро, но не поддерживает составной ключ, поэтому я создаю один ключ, который на самом деле является составным ключом. В SQL Int32A Int32B образуют PK.
Причина, по которой я не использую составной ключ, заключается в том, что мне нужна скорость поиска в словаре, и, насколько мне известно, словарь не поддерживает составной ключ. Это производственный код. В таблице SQL фактически есть третий ключ (Int32 sID, Int32 IntA, Int32 IntB). В этом парсере я имею дело только с одним sID одновременно (и sID обрабатываются по порядку). Я начал с поиска составного ключа в SQL (миллиарды за раз). Когда я вытащил IntA, IntB из словаря для обработки одного sID, а затем загрузил в SQL по завершении каждого sID, я получил улучшение производительности на 100: 1. Часть улучшения производительности - вставка, так как когда я вставляю из словаря, я могу вставлять в порядке PK. Новые IntA и IntB не производятся отсортированными при разборе, поэтому прямая вставка в SQL может серьезно фрагментировать индекс, и мне нужно будет перестроить индекс в конце прогона.