Здравствуйте, Don Reba, Вы писали:
W>>А смысл это все иметь в памяти? W>>Почему бы не использовать, например,SQLite ?
DR>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
Здравствуйте, Win32nipuh, Вы писали:
W>так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ?
SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ? O>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
Подробности не описаны в вопросе ТС.
Вы слово "СУБД" использовали в кавычках, не знаю, можно ли назвать SQLite СУБд или встраиваемой, это уже игра слов.
Здравствуйте, Win32nipuh, Вы писали:
W>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов. W>Подробности не описаны в вопросе ТС.
А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>>>
I>>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Ф>>Я не про скорость в данном случае.
I>Тот же децимал вдвое больше дабла. Это скользкий момент. Без учета основных операций над числом нет оснований просто так распылять память.
Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors.
Decimal is not a floating-point data type.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors. Ф>Decimal is not a floating-point data type.
Я в курсе. А разве где то было указано, что есть вот такие особенные вычисления ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Some calculations, such as financial, require a large number of digits but cannot tolerate rounding errors. Ф>>Decimal is not a floating-point data type.
I>Я в курсе. А разве где то было указано, что есть вот такие особенные вычисления ?
Поле "цена" — это уже финансовые вычисления. Вычисления начинаются в момент приведения типа (Log10 -> Log2), т.е. когда ты сохраняешь эту цену как double. До и после этого скорее всего будут такие операции как суммирование, умножение (n*price, percents * AmountOfTransaction, ... etc), и я очень надеюсь, что они происходят не с даблами.
Даже если это покупка или продажа акций, то уже будет и сумма, и удержание процентов с операции (умножение), и вычитание: Account -= AmountOfTransaction.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Поле "цена" — это уже финансовые вычисления.
Поле цена это просто поле цена. Я например год работал на проекте, где лет пять до того цену хранили даблом. И никаких проблем с погрешностью не было. Не просто никаких, а абсолютно никаких.
Так что не все вычисления можно и нужно относить к 'финансовым'.
Здравствуйте, okon, Вы писали:
O>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ? O>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
На счет сортировки — SQL бд точно умеет быстро сортировать. Вот искать — далеко не факт.
Здравствуйте, Ikemefula, Вы писали:
I>Поле цена это просто поле цена. Я например год работал на проекте, где лет пять до того цену хранили даблом. И никаких проблем с погрешностью не было. Не просто никаких, а абсолютно никаких. I>Так что не все вычисления можно и нужно относить к 'финансовым'.
Ты ведь зачем-то используешь double вместо float. То есть какая-то зависимость от погрешности есть.
Умные люди в больших проектах на таких вот ошибках вычисления с плавающей точкой делают хорошие деньги, выводя из оборота тысячные доли копеек.
Кроме того GetHashCode() вычисляет хэш по байтам double'а (приводя Double* к Int64*), а, значит, ошибка с плавающей точкой приведёт тебя к тому, что ты не сможешь найти значение в словаре по указанному значению (будет 9,99999999999998 вместо 10.0 и т.д.).
Если же ты ищешь по тем самым Double'ам, которые сохранены у тебя в твоих объектах — фактически, используешь их как индексы, то... я бы за такое бил по рукам, но в условиях дефицита памяти на что люди только не идут. Как я писал выше, для Dictionary не важно — индексируешься ты по Double или по Int64. Но у тебя чертовски толстая коллекция с вероятностью коллизии хэшей 1/143, что в общем-то дохрена. Поэтому я бы, на твоём месте, разбил словарь на кучку более мелких, по ценовым диапазонам — и будет тебе счастье.
Но я всё же рекомендую переосмыслить подход к индексации записей.
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Albeoris, Вы писали:
A>Кроме того GetHashCode() вычисляет хэш по байтам double'а (приводя Double* к Int64*), а, значит, ошибка с плавающей точкой приведёт тебя к тому, что ты не сможешь найти значение в словаре по указанному значению (будет 9,99999999999998 вместо 10.0 и т.д.).
Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью.
Потому нет смысла говорить про децимал, пока нет ясности с операциями.
Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию !
A>Если же ты ищешь по тем самым Double'ам, которые сохранены у тебя в твоих объектах — фактически, используешь их как индексы, то... я бы за такое бил по рукам,
Одни хотят бить за даблы, другие — за их отсутствие. Нужно внятно говорить, какую проблему хочется решить на основании каких именно догадок
> но в условиях дефицита памяти на что люди только не идут. Как я писал выше, для Dictionary не важно — индексируешься ты по Double или по Int64. Но у тебя чертовски толстая коллекция с вероятностью коллизии хэшей 1/143, что в общем-то дохрена.
Откуда 1/143 ?
>Поэтому я бы, на твоём месте, разбил словарь на кучку более мелких, по ценовым диапазонам — и будет тебе счастье.
I>Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью. I>Потому нет смысла говорить про децимал, пока нет ясности с операциями. I>Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию !
И зачем мне это курить, если ты сам подтверждаешь мои слова? Single даст ещё большую оптимизацию и по памяти и по быстродействию. И если ты разрабатываешь приложение, которое работает с живыми деньгами, то завязываться на то, что за всё время жизни алгоритмы получения этих циферок не поменяются — не очень хорошая мысль.
I>Откуда 1/143 ?
Весьма грубая прикидка сделанная на основе того, что в коллекции 30 000 000 записей и предположения, что на этот момент коллизий нет (что наверняка противоречит действительности). Понятно, что в итоге она стремится к 0,99999999976716935634613037109375, так как мы вычисляем 32-битный хэш от 64-битного целого. Так что корзины у автора уже наверняка формируются. Будет больше записей — будет ещё больше корзин, поиск по словарю замедлится ещё сильнее.
I>Спасибо, я передам топикстартеру.
Спасибо. (=
P.S. Ты так отстаивал текущую модель, что я не обратил внимания.
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
I>>Если вычисления сделаны одинаковые, то и значения будут идентичные. А если ты в одном месте считашь логариф, а в другом делаешь ровно то же, но через сложение-умножение-деление, то результаты будут с погрешностью. I>>Потому нет смысла говорить про децимал, пока нет ясности с операциями. I>>Если все условия соблюдены, то дабл может дать внятную оптимизацию и по памяти и по быстродействию ! A>И зачем мне это курить, если ты сам подтверждаешь мои слова? Single даст ещё большую оптимизацию и по памяти и по быстродействию. И если ты разрабатываешь приложение, которое работает с живыми деньгами, то завязываться на то, что за всё время жизни алгоритмы получения этих циферок не поменяются — не очень хорошая мысль.
Ну вот я работал с таким приложением и все было на даблах еще за пять лет до меня. Никаких проблем, объяснения магии — в ссылке
I>>Спасибо, я передам топикстартеру. A>Спасибо. (= A>P.S. Ты так отстаивал текущую модель, что я не обратил внимания.
Я отстаиваю простую вещь — дабл vs децимал есть оффтопик.
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
Это серверное приложение, я надеюсь, не толстый клиент?
Если серверное приложение, то зачем ему всё грузить сразу в память?
Почему не провести подсчёты в СУБД? На худой конец в NoSQL какой-нить, которая всё в памяти держит *под это нужна машина, конечно или лучше кластер*
Здравствуйте, Ikemefula, Вы писали:
I>Я отстаиваю простую вещь — дабл vs децимал есть оффтопик.
Да я солидарен с тобой, поэтому предложил конкретное решение конкретной проблемы. Но когда деньги (потенциально, мои) начинают хранить в Doubla'ах, во мне просыпается кровожадное чудовище. Я понимаю, что всё это из области наколенных программ для домашнего использования, но однажды такие программисты придут в какой-нибудь "Сбербанк", и деньги со счетов тонкой струйкой потекут в тёплые страны. Не благодаря стечению обстоятельств, а по конкретному злому умыслу, эксплуатирующему уязвимость.
P.S. Мысль! Ну мысль же! Ааа... чёртовы thing'и! X"D
"Хаос всегда побеждает порядок, поскольку лучше организован." (с) Терри Пратчетт
Здравствуйте, Albeoris, Вы писали:
I>>Я отстаиваю простую вещь — дабл vs децимал есть оффтопик. A>Да я солидарен с тобой, поэтому предложил конкретное решение конкретной проблемы. Но когда деньги (потенциально, мои) начинают хранить в Doubla'ах, во мне просыпается кровожадное чудовище. Я понимаю, что всё это из области наколенных программ для домашнего использования,
Ты предложил 'как делать правильно во всех случаях где есть цена потому что иначе неправильно даже если работает правильно'
