Здравствуйте, CreatorCray, Вы писали:

CC>Ты посчитай сколько памяти займут эти строки?

CC>На 10к строк С# падает с out of memory
??? Не падает. Выполняется за 3.9 сек.

CC>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.
1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.

Здравствуйте, alexey_ma, Вы писали:


_>>>Почти все крупные компании используют готовые решения.

C>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?
_>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.

Здравствуйте, alexey_ma, Вы писали:



_>>>У вас в коде вроде тоже замена одиночного символа
C>>Речь шла о замене именно подстроки. Я могу поменять замену символа на замену подстроки из десятков символов и принципиального падения производительности не будет.
_>Уверены ?
_>У меня ваш код при замене
_>

_>stringBuilder.Replace('1', '2');

_>на
_>

_>stringBuilder.Replace("c1", "12");

_>Выбрасывает System.OutOfMemoryException.

У меня отрабатывает за 4.9 сек (против 2.9 сек на замену одного символа). Ну раз у Вас не достаточно памяти, то уменьшите количество иттераций в несколько раз.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, alexey_ma, Вы писали:


_>>>>Почти все крупные компании используют готовые решения.

C>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?
_>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.
Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Serginio1, Вы писали:

S>>Согласен, что врайт барьера не будет,так как создаются новые узлы, но будет фрагментация кучи старших поколений, если освободившиеся узлы в них лежат.
WH>Какая еще фрагментация в случае с уплотняющим мусорщиком?

На дефрагментацию кучи время уходит? И это может происходить достаточно часто. Все зависит от емкости, и скорости изменения дерева.
S>>Кстати а как там с балансировкой дерева?
WH>2-3 дерево. Частный случай B дерева. Еще вопросы?

Прибавляй затраты на балансировку.
Я к тому, что много дополнительных затрат, которые по уму нужно учитывать, при выборе типа инструмента.
Но ни вкоем случае не против веревок. Для каждой задачи свой алгоритм. Чем больше тем лучше.
Поэтому и убежден, что 3 на бора строк это лучше чем 1 универсальный, но с реализацией одинаковых интерфейсов.
Нет серебрянной пули.
Спасибо, вопросов пока нет.

Здравствуйте, WolfHound, Вы писали:

И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.

Здравствуйте, alexey_ma, Вы писали:

_>>>>>Почти все крупные компании используют готовые решения.

C>>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?
_>>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.
_>Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".

Конечно на заказ — иначе и не выйдет, т.к. требования у всех разные и хотя подсистемы типа call-центров, crm, erp и т.д. могут быть адаптированны под условиях конкретно взятой компании, то в ЦЕЛОМ enterprise система для каждой компании своя уникальная.

Иными словами, Вы явно не понимаете о чем говорите.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, alexey_ma, Вы писали:

_>>>>>>Почти все крупные компании используют готовые решения.

C>>>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?
_>>>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>>>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.
_>>Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".

C>Конечно на заказ — иначе и не выйдет, т.к. требования у всех разные и хотя подсистемы типа call-центров, crm, erp и т.д. могут быть адаптированны под условиях конкретно взятой компании, то в ЦЕЛОМ enterprise система для каждой компании своя уникальная.
Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.

Здравствуйте, alexey_ma, Вы писали:


_>Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.

Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).

Здравствуйте, criosray, Вы писали:

C>Ну и кроме того, я могу сполна доверять стандартным классам фреймворка, а вот левой библиотеке некоего Васи Пупкина (ничего личного, я так для примера) — без соответствующего code review доверять ну никак не смогу.
C>Да и вообще зачем изобретать велосипед? Сколько уже было потрачено человеко часов для такой банальщины, как преобразование базовых типов для вывода в строку?..
Ну .NET FW же изобрели.
Опять куда то не туда ушла дискуссия.

C>>>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".
CC>>Мне тоже не приходится.
C>Про _itow_s Вы знали на генетическом уровне? Да?
Ага. Зная про itoa "гены" начали мне подсказывать что есть и itow.

Здравствуйте, criosray, Вы писали:

c> _>Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.

c> Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).

Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования

Здравствуйте, Mamut, Вы писали:

c>> _>Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.

c>> Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).

M>Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования

Мы таких не держим.

Здравствуйте, CreatorCray, Вы писали:

C>>Ну и кроме того, я могу сполна доверять стандартным классам фреймворка, а вот левой библиотеке некоего Васи Пупкина (ничего личного, я так для примера) — без соответствующего code review доверять ну никак не смогу.
C>>Да и вообще зачем изобретать велосипед? Сколько уже было потрачено человеко часов для такой банальщины, как преобразование базовых типов для вывода в строку?..
CC>Ну .NET FW же изобрели.
CC>Опять куда то не туда ушла дискуссия.

А куда ей еще уйти? Все еще раз и еще раз сводится к примитивизму С++, как платформы, где даже такая элементращина, как преобразование типов, требует штудирования MSDN, а для банального replace всех вхождений подстроки в строку надо подкючать стороннюю библиотеку типа boost.

C>>>>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".
CC>>>Мне тоже не приходится.
C>>Про _itow_s Вы знали на генетическом уровне? Да?
CC>Ага. Зная про itoa "гены" начали мне подсказывать что есть и itow.
itoa Вы, поди, тоже знали на генетическом уровне?

Здравствуйте, Serginio1, Вы писали:

S>На дефрагментацию кучи время уходит? И это может происходить достаточно часто. Все зависит от емкости, и скорости изменения дерева.
Чё? Дефрагментация кучи происходит во время сборки мусора.
Причем я тут можно очень серьезно срезать углы по сравнения с изменяемой кучей.

WH>>2-3 дерево. Частный случай B дерева. Еще вопросы?
S> Прибавляй затраты на балансировку.
Какую балансировку?
B дерево строится сбалансированным сразу.
Ты вообще представляешь как работают B деревья?
Или мне тут нужно всем лекции по структурам данных прочитать?

S> Я к тому, что много дополнительных затрат, которые по уму нужно учитывать, при выборе типа инструмента.
Каких?

S>Поэтому и убежден, что 3 на бора строк это лучше чем 1 универсальный,
Хуже. Причем сильно хуже.

S>но с реализацией одинаковых интерфейсов.
Одинаковые интерфейсы у изменяемых и неизменяемых структур данных просто сюр.

Здравствуйте, criosray, Вы писали:

C>И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.
Я уже третий раз эту ссылку привожу http://www.ibm.com/developerworks/java/library/j-ropes/index.html

For example, the ICFP 2007 Programming Contest involved implementing a virtual machine that modified its state with every cycle and ran for millions of cycles for some inputs (see Resources). In one Java implementation, the virtual machine's speed was improved by three orders of magnitude, from ~50 cycles/sec to more than 50,000/sec, by changing the state representation to use a Rope instead of a specialized StringBuffer.

Я конечно понимаю что пример весьма клинический но разгон алгоритма на 3 порядка....

Здравствуйте, WolfHound, Вы писали:

C>>И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.
WH>Я уже третий раз эту ссылку привожу http://www.ibm.com/developerworks/java/library/j-ropes/index.html
Ссылку эту я видел, но исходника я там не нашел. Плохо искал? И хотелось бы все-таки .NET реализацию увидеть...

Здравствуйте, criosray, Вы писали:

C>Ссылку эту я видел, но исходника я там не нашел. Плохо искал?
2 клика: http://ahmadsoft.org/ropes/release.html

C>И хотелось бы все-таки .NET реализацию увидеть...
Незнаю не искал.

Здравствуйте, criosray, Вы писали:

C>Ссылку эту я видел, но исходника я там не нашел. Плохо искал? И хотелось бы все-таки .NET реализацию увидеть...

Например, здесь

Здравствуйте, Serginio1, Вы писали:

K>>Это для вставки. А не для добавления к началу/концу т.е. конкатенации.
S>Может я чего то не понимаю — В чем разница? Так структура мутабельна мы должны выделить новыю ссылку на корень,и от него добраться либо в конец либо в начало,
S>выделяя новую ветку, с модификациу длины?

1) Для конкатенации не нужно добираться в конец или в начало.
2) Быстрый доступ к концу и началу можно организовать с помощью двух "пальцев" указывающих на самый левый и самый правый узлы (удерживать их всегда в первом уровне дерева). Но для конкатенации это не нужно, это нужно если мы хотим чтобы строки у нас были деком с константным доступом.

S>По уму нужно еще сложность балансировки добавлять, т.к. деревья могут вырождаться в двухнапрвленный список.

Это все учтено. Сложность вставки О(1) — амортизированная.

Здравствуйте, criosray, Вы писали:

M>>Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования
C>Мы таких не держим.

Ну ты вот, например, тут почти круглосуточно трендишь...