Здравствуйте, VladD2, Вы писали:
VD>Ровно настолько насколько разные реализации хэш-таблиц отличаются друг-от друга.
Не совсем. Та, которая хранится на диске (и не грузится в память целиком), должна быть заточена под минимизацию перемещений головки. А если перенести тупо хеш для памяти на диск путем выдачи адресов из дискового мепа, ничего хорошего скорее всего не получится.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не совсем. Та, которая хранится на диске (и не грузится в память целиком), должна быть заточена под минимизацию перемещений головки. А если перенести тупо хеш для памяти на диск путем выдачи адресов из дискового мепа, ничего хорошего скорее всего не получится.
Кхм.... Swap file?
Здравствуйте, Cyberax, Вы писали:
C>Тогда почему C#овцы в каждом втором слуае хвалятся огромной стандартной библиотекой? (А в каждом первом случае хвалятся портируемостью)
Спроси у этих мифических "C#овцы".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не совсем. Та, которая хранится на диске (и не грузится в память целиком), должна быть заточена под минимизацию перемещений головки. А если перенести тупо хеш для памяти на диск путем выдачи адресов из дискового мепа, ничего хорошего скорее всего не получится.
Это вопрос выбора хэш-функции, а не реализации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Я бы сильно удивился, если бы в Windows нашелся MS-ный компонент, скомпилированный Borland-ом или, прости господи, GNU C++
Ну, при переносе на разные Мипсы/Альфи они были вынуждены сделать код универсальным. Но это в основном этот окд как раз на С написан. На С++ написаны такие нетленки как Write.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не ссорьтесь, горячие парни Решается всё просто — ставите себе debug symbols и смотрите на имена функций. Статистику не мерял, но "на глаз" в XP процентов 80-90 кода на С++.
AVK>RB деревья как раз используются при необходимости. А вот В+ в реальных проектах я не видел ни разу.
Symbian OS — в стандартной библиотеке есть реализация B-деревьев. IMHO, переходить от B к B+ имеет смысл только если они лежат на диске — для работы с памятью B-деревья предпочтительнее B+.
AVK>>Не совсем. Та, которая хранится на диске (и не грузится в память целиком), должна быть заточена под минимизацию перемещений головки. А если перенести тупо хеш для памяти на диск путем выдачи адресов из дискового мепа, ничего хорошего скорее всего не получится.
VD>Это вопрос выбора хэш-функции, а не реализации.
Сильно сомневаюсь что это хорошая идея — хранить данные на диске через хеш-таблицу. Слишком медленным получится последовательное чтение — поскольку прийдётся скакать случайным образом по всей таблице. Хотя, может для каких-то специфических задач это и прокатит... Впрочем, при добавлении в RB-дерево случайным образом страницы тоже могут перемешаться на диске — но тут по крайней мере можно слегка прогнуться и сделать дефрагментацию, а вот хеш-таблицу ничто не спасёт
Здравствуйте, AndrewVK, Вы писали:
V>>Гораздо интереснее время выделения памяти. А оно практически одинаковое.
AVK>Было бы странно, если бы и там была разница.
Там может быть разница, ибо GC от MS напрямую откусывает из виртуальной памяти. Не знаю как сделано в Mono, но из-за его многоплатформенности именно этот момент — эффективное управление большими кусками памяти, весьма специфичный для каждой платформы.
Здравствуйте, Left2, Вы писали:
L>Symbian OS — в стандартной библиотеке есть реализация B-деревьев. IMHO, переходить от B к B+ имеет смысл только если они лежат на диске — для работы с памятью B-деревья предпочтительнее B+.
Здравствуйте, VladD2, Вы писали:
VD>Ты за свой проффесионализм бойся, а за мой не надо. Я понимаю что говорю. В большинстве случаев порвет. А тот 1-2% происходят когда оптимизацией занимаются действительно знающие люди и в довольно редких случаях. Пока хорошему ЖЦ хватает памяти он весьма эффективен.
ООО, ещё один великий ГУРУ нашёлся, ну надо же...
Судя по стилю постов — недавний студент
VD>Вот и срани как нибудь эти реализации. ЖЦ под обычным С++ — это слезы.
Ну вот сам и сравни, только не облажайся в С++ — коде...
Здравствуйте, LeeMouse, Вы писали:
LM>ООО, ещё один великий ГУРУ нашёлся, ну надо же... LM>Судя по стилю постов — недавний студент
VD>>Вот и срани как нибудь эти реализации. ЖЦ под обычным С++ — это слезы.
LM>Ну вот сам и сравни, только не облажайся в С++ — коде...
Что можно сказать о этих словах без перехода на твою личность? Да в общем-то ничего. А так как обсуждение твоей личности неимет никакого смысла, то лучше промолчу.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Left2, Вы писали:
L>Сильно сомневаюсь что это хорошая идея — хранить данные на диске через хеш-таблицу.
Дык это не вопрос твоих сомнений. Этот тип индксов применяется не в одной СУБД. И не только в СУБД.
L> Слишком медленным получится последовательное чтение — поскольку прийдётся скакать случайным образом по всей таблице.
Не всегда нужно последовательное сканирование. Бывает так, что по индексу делается только лукап. И хэш-индекс позволяет сделать его быстрее всего, если коенчно нет проблем с хэш-функцией и количеством кластеров.
L> Хотя, может для каких-то специфических задач это и прокатит... Впрочем, при добавлении в RB-дерево случайным образом страницы тоже могут перемешаться на диске — но тут по крайней мере можно слегка прогнуться и сделать дефрагментацию, а вот хеш-таблицу ничто не спасёт
RB-дерево — это структура данных не предназначенная для хранения на диске. RB-дерево — это обычное бинарное дерево (т.е. ветка состоит из двух элементов) снабженная "цветами" для корректировки сбалансированности. Ты видимо хотел сказать B-дерево, или B+-дерево.
В них страницы не перемещаются. Основаня операция в них — это разделение страницы. Когда страница переполняется, то она делится на две. Перемещается при этом только часть данных прошлой страницы. Что в общем-то фигня.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Влад, насколько я понимаю изначально разговор шёл о том что с помощью С++ аллокаторов можно хранить на диске контейнеры. Я имел в виду стандартные С++ контейнеры — std::map и stdext::hash_map. Что такое B и B+ дерево я себе представляю, в институте учили, но как тут выше заметили B(+) деревьев обычно в библиотеках шаблонов нет.
Здравствуйте, Left2, Вы писали:
L>Влад, насколько я понимаю изначально разговор шёл о том что с помощью С++ аллокаторов можно хранить на диске контейнеры. Я имел в виду стандартные С++ контейнеры — std::map и stdext::hash_map. Что такое B и B+ дерево я себе представляю, в институте учили, но как тут выше заметили B(+) деревьев обычно в библиотеках шаблонов нет.
Правильно и посему вместо выбора подходящих структур данных и алгоритмов мы будем через одно место пытаться хнанить на дисках std::map-ы. Гениально! Блин, Кнут при жизни в гробу перевернется.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Left2, Вы писали:
L>Symbian OS — в стандартной библиотеке есть реализация B-деревьев. IMHO, переходить от B к B+ имеет смысл только если они лежат на диске — для работы с памятью B-деревья предпочтительнее B+.
Вообще-то B+ отличаются очень незначительно. Это небольшое усовершенствование. Просто связали страницы двунаправленным списком и все. Оно и в памяти удобнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Правильно и посему вместо выбора подходящих структур данных и алгоритмов > мы будем через одно место пытаться хнанить на дисках std::map-ы. > Гениально! Блин, Кнут при жизни в гробу перевернется.
Вообще-то, с помощью такого приема можно хранить на диске _любые_
данные. В том числе и те, которые плохо ложаться в реляционную модель
(например, большой битмап).
Причем работа с ними будет абсолютно прозрачна для меня.
Решается всё просто — ставите себе debug symbols и смотрите на имена функций. Статистику не мерял, но "на глаз" в XP процентов 80-90 кода на С++.
