Comments 12
Хм… что-то напомнило db4o
Ну, ООСУБД — это область, в которой пока можно писать велосипеды, особенно под ДотНет =) Может, что-то интересное и получится.
+1 за сомоотверженную работу
-1 за отсутствие хотя бы чего-нибудь нового (будь то идея, дизайн или технология)
П.С. диаграмма классов из одного «кубика» — признак того, что вы как-то неудачно выбрали парадигму.
-1 за отсутствие хотя бы чего-нибудь нового (будь то идея, дизайн или технология)
П.С. диаграмма классов из одного «кубика» — признак того, что вы как-то неудачно выбрали парадигму.
Диаграмма классов не полная, только то что нужно для использования. Новое — burst read/write страниц «работа с большими файлами происходит зачастую быстрее и если разработчик догадывается как это можно сделать эффективнее в его приложении то производительность записи можно существенно увеличить (Ценой надёжности естественно).». Но наши недостатки — продолжения наших достоинств, если нужно 10 объектов и они лежат в одном файле — это плюс, если они лежат в 10 файлах это очень существенный тормоз.
о фрагментации хранилища замолвите слово… как только оно вылезет за пределы кеширования, мы приплыли…
А зачем вы в IndexingManager явно вызываете GC.Collect()?
Что бы раньше освободить память
а зачем? GC во-первых сам сделает это тогда, когда ему удобно. К тому же если у вас много всякой всячины во втором поколении — это элементарно воткнет.
А если в программе есть какие-то кэши на week? Этот код тогда тем более добавит тормозов.
Если вы боитесь Out Of Memory, то GC всегда делает последнюю попытку перед тем как кинуть исключение.
А если в программе есть какие-то кэши на week? Этот код тогда тем более добавит тормозов.
Если вы боитесь Out Of Memory, то GC всегда делает последнюю попытку перед тем как кинуть исключение.
ОК, спасибо.
Sign up to leave a comment.
Игрушечная ООСУБД