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

S> Inline это уже прерогатива C++.

Не говори ерунду. Автоинлайнинг делается джитом. Нругое дело, что VC-шный оптимизатор порой делает это эффективнее, и в том, что после этого он делает еще набор оптимизаций. В итоге получается комулитивный эффект.

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

Компилятору намного лучше виднее что нужно инлайнить, а что нет. Есть и матиматические методы, и основанные профилировании. Просто в дотнете это пока не сделано, да и это занимает некоторое время, так что они могут просто экономить на компиляции.

S> Возможно по просьбам трудящихся и введуд эту дериктиву.

Никогда в жизни. Это была ошибка в плюсах. Эта так же полезно как размножение кода копи-пэстом и использование goto. Серьезные программисты и архитекторы таких глупостей не допускают.

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

VD>На этот вопрос тебе мы с АВК уже отвечали не раз. Делай кодогенерилку. А может и вообще спец язык. Делегаты точно не для таких объемов. Делегаты оптимальны для легкого расширения функциональности классов без неследования. Ну, такм реакция на нажатие... собственная отрисовка... в общем, по мелочи.

Чтото вы говорили, это точно Только на проверку оказалось фигней. Без обид.


PE>>Это не всегда возможно. Например при десерилизации бинариформаттером.
VD>При десиреализации делегаты уже тебя не спасут. Такие объему нужно сериализовать самостоятельно. Об этом мы тоже говорили.

VD>Создавай массив делегатов вручную. Будет линейное замеделение.
Это не всегда возможно. Например при десерилизации бинариформаттером.

Для тех, кто на бронепоезде.
При серилизации объектов любых классов с делегатами обеспечен геморрой, если используется бинариформаттер.

В том, что нужен сериалайзер, никто не сомневался. Только реального предложения ты дать не смог. Текст
на 3rd-parties сборки не сгенерируешь.

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

VD>>На этот вопрос тебе мы с АВК уже отвечали не раз. Делай кодогенерилку. А может и вообще спец язык. Делегаты точно не для таких объемов. Делегаты оптимальны для легкого расширения функциональности классов без неследования. Ну, такм реакция на нажатие... собственная отрисовка... в общем, по мелочи.

PE>Чтото вы говорили, это точно

Ну, конечно. Вот только что АВК работает с окромными массивами объектов, что я. П все летает. А у тебя проблема на проблеме.

PE>Только на проверку оказалось фигней. Без обид.

Да что обижаться то? Просто ты уже начинаешь утомлять этими вопросами.

PE>>>Это не всегда возможно. Например при десерилизации бинариформаттером.
VD>>При десиреализации делегаты уже тебя не спасут. Такие объему нужно сериализовать самостоятельно. Об этом мы тоже говорили.

PE>

VD>>Создавай массив делегатов вручную. Будет линейное замеделение.
PE>Это не всегда возможно. Например при десерилизации бинариформаттером.

И? Ты используеш плохое решение и еще обжаешся на него. Тебе об этом говорят. Или ты хочешь плучать разные ответы в разное время?

PE>Для тех, кто на бронепоезде.

Для себя что ли? Тож без обид.

PE>При серилизации объектов любых классов с делегатами обеспечен геморрой, если используется бинариформаттер.

Так не испоьзуй? Ало! В танке...

PE>В том, что нужен сериалайзер, никто не сомневался. Только реального предложения ты дать не смог. Текст
PE>на 3rd-parties сборки не сгенерируешь.

1. Сгенерируешь.
2. У тебя что чужие сборки?

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

VD>Ну, конечно. Вот только что АВК работает с окромными массивами объектов, что я. П все летает. А у тебя проблема на проблеме.

Огромные массивы и у меня летают. Тормоза совсем в другом. Такие же проблемы возникают и в других областях, в которых модель описывается тысячами уравнений и констраинтов.

Для таких систем есть Modelica. Можешь глянуть, что это такое.
Хорошая вещь, но все требования заказчика покрыть не удается. Ибо ни c COM, ни с .Net не дружит. Есть еще масса геморроя с ней.

VD>1. Сгенерируешь.

Что именно сгенерируешь ? Давай поподробнее.

VD>2. У тебя что чужие сборки?
Конечно, есть и такие.

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

VD>Как бы их найти?

Дык в CVS

M>>Так ведь и сделали.
S> Интересно а сколько китайских, японских,корейских, мумба юмбовских иероглифов ????

Китайских — двадцать тысяч может и наберётся. Корейские и японские на 99% являются подмножеством китайских. Например, в японском языке, если вспомнить редкие и устаревшие формы — порядка 10-12 тыс. Из них, наверное, меньше 1 тыс своих, остальные те же китайские. Кстати, в реальном использовании нормального японца ну хорошо если тысячи 3-4. И из них штук сто, может, чисто японских.

А про юмбовских не знаю.


S> Только и юникод на самом деле не 2 байтный. Поэтому и применяют символы расширения.

Да, не совсем двухбайтный. Но символы расширения применяют в основном для арабских туда-сюда приколов и для всяких абракадабро-медицинских и диффренциально-математических значков. У арабов, понимаешь, принципиально рукописный текст. Все эти завитушки, связки между соседними "буквочками" и т.п.

Но здесь как раз можно пойти на поводу общепринятого стандарта, и обрабатывать юникод как он забит в .NET и Windows. Пусть арабы сначала сами с собой разберутся, а то, может, через лет пять не будет вообще никаких арабов с их алфавитом. Нет арабов — нет проблемы


M>>Это как для поиска в БД? Там же SQL, а не Regex
S> Скульщики несчаясные. ЛОКАЛЬНЫЕ БД.

Ты считаешь себя таким хорошим специалистом, что пишешь собственный DB Engine? Вообще говоря, это хорошо укладывается в твой колоритный портрет


M>>Вообще я последние несколько месяцев консультирую одного товарища-япониста. Наш товарищ, и разрабатывает он софт типа словаря с японским текстом. На Дельфи. И одна из надоевших проблем — тупая поддержка юникода в Дельфи (используется версия до .NET).
S> Дык пусть переходит на Net. Правда еще сырая, но 2 апдейт вышел.

Ну я уважаю выбор других людей. Лично я бы в таком случае советовал C#, а не Delphi.NET. Впрочем, это тема отдельной войны.

VD>Так что все будет ОК. Или МС поправит свои коллекции или мы родим свои.

Точно.

Написать нормальный List — день. Ну ещё день на совесть оттестировать и оптимизировать.

VD>>>>Выносит ли Джит проверку длинны массива за пределы цыкла?

M>>>>По словам Микрософта, выносит. И даже foreach разворачивает в for.

VD>>>Меньше читай рекламы по утрам.

M>>А ты как проверял?

VD>Открыл анакриной или еще чем-то и посмотрел.

Анакрина вообще не позволяет делать никаких предположений об оптимизациях JIT.

Или ты что-то недоговариваешь, или не на тот вопрос ответил

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

VD>>Так что все будет ОК. Или МС поправит свои коллекции или мы родим свои.

M>Точно.

M>Написать нормальный List — день. Ну ещё день на совесть оттестировать и оптимизировать.

оптимист...

неделя минимум... а про тестинг это вообще на месяц затянуться может...
а в результате должен получиться не быстрый класс, а надежный!!! и по мере сил быстрым...

у макрософта на первом плане надежность, а только потом скорость... по-этому скорее всего местами прийдеться переписывать классы и получать маленький прирост по скорости

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

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

AVK>>Ты по единственному примитивному регексу уже сделал вывод общий? Твои регексы look ahead поддерживают к примеру?

VD>Боюсь, он тебя просто не поймет. Он же сказал, что с самими регекспами знаком слабо. Так что поясню.

VD>Лук эхэд — это значит заглядывание вперед, ну, возможность сделать предусловие. Т.е. найти "яяя" которому предшествует (или наоборот, не предшествует) некое выражение. Это кстати умеют многие реализации. Дотнетная же умеет еще и назад смотреть (пост условия делать).
Это то я понял. Разобрался уже с регулярными выражениями (правда look ahead понял по наитию поддерживают шаблоны (?=,?!) ).
В принцыпе их не долго и реализовать. Просто если общий код бакнеловских 30 кб из которых половина коментарии то нетовских без regexcompiler.cs 380 кб
А например такой образец

string Pattern= @"(function .+\(.+\) *: *.+)|";
Pattern+=@"(procedure .+\(.+\))|";
Pattern+=@"(property .+read .+)";
Pattern+=@" *;";

В этой строке как раз нет CharClass.
На на нетовскх регэкспах вообще тормозит в 3 раза. Delphi выигрывает совсем немного 10-15%.
На выходных буду Яву изучать.
Может и посмотрю на типизированной хэштаблице char (5 минут работы) при работе с CharClass все таки перед Дельфийным Set (BitArray)
И все приведу в порядок.

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

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

S>> Да это все понятно. Талица переходов будет еще та и количество pop и push а они и являются главным тормозом.

VD>Я конечно не знаком с алгоритмами применяемыми в твоей реализации, но для поиска вариантов есть два эффектинвых решения. Первое полноценный ДКА, т.е. на любое состояние имеется список единственно возможных переходов. Воторой — специльная обработка конструкций (ххх|yyy|...) и засовывание вариантов в хэш-таблицу.

S>> Но мне не понятно почему бакнелловские (в моей редакции) хоть и урезанные в 2 раза быстрее нетовских. Даже компиляция для IgnoreCase не помогает ????

VD>А мне не понятно почему твои всего в два раза быстрее. Нетовские с точки зрения скорости совсем бездарно написаны.

Там все достаточно просто. На такую строку

 string Pattern= @"(function .+\(.+\) *: *.+)|";
        Pattern+=@"(procedure .+\(.+\))|";
        Pattern+=@"(property .+read .+)";
        Pattern+=@" *;";

Строится таблица переходов

     Start Pos=39
0  mtChar,F,2,-1
1  mtUnused--------------
2  mtChar,U,4,-1
3  mtUnused--------------
4  mtChar,N,6,-1
5  mtUnused--------------
6  mtChar,C,8,-1
7  mtUnused--------------
8  mtChar,T,10,-1
9  mtUnused--------------
10  mtChar,I,12,-1
11  mtUnused--------------
12  mtChar,O,14,-1
13  mtUnused--------------
14  mtChar,N,16,-1
15  mtUnused--------------
16  mtChar, ,18,-1
17  mtUnused--------------
18  mtAnyChar,19,-1
19  mtNone,21,18
20  mtUnused--------------
21  mtChar,(,23,-1
22  mtUnused--------------
23  mtAnyChar,24,-1
24  mtNone,26,23
25  mtUnused--------------
26  mtChar,),29,-1
27  mtUnused--------------
28  mtChar, ,29,-1
29  mtNone,31,28
30  mtUnused--------------
31  mtChar,:,34,-1
32  mtUnused--------------
33  mtChar, ,34,-1
34  mtNone,36,33
35  mtUnused--------------
36  mtAnyChar,37,-1
37  mtNone,109,36
38  mtUnused--------------
39  mtNone,0,70
40  mtChar,P,42,-1
41  mtUnused--------------
42  mtChar,R,44,-1
43  mtUnused--------------
44  mtChar,O,46,-1
45  mtUnused--------------
46  mtChar,C,48,-1
47  mtUnused--------------
48  mtChar,E,50,-1
49  mtUnused--------------
50  mtChar,D,52,-1
51  mtUnused--------------
52  mtChar,U,54,-1
53  mtUnused--------------
54  mtChar,R,56,-1
55  mtUnused--------------
56  mtChar,E,58,-1
57  mtUnused--------------
58  mtChar, ,60,-1
59  mtUnused--------------
60  mtAnyChar,61,-1
61  mtNone,63,60
62  mtUnused--------------
63  mtChar,(,65,-1
64  mtUnused--------------
65  mtAnyChar,66,-1
66  mtNone,68,65
67  mtUnused--------------
68  mtChar,),109,-1
69  mtUnused--------------
70  mtNone,40,71
71  mtChar,P,73,-1
72  mtUnused--------------
73  mtChar,R,75,-1
74  mtUnused--------------
75  mtChar,O,77,-1
76  mtUnused--------------
77  mtChar,P,79,-1
78  mtUnused--------------
79  mtChar,E,81,-1
80  mtUnused--------------
81  mtChar,R,83,-1
82  mtUnused--------------
83  mtChar,T,85,-1
84  mtUnused--------------
85  mtChar,Y,87,-1
86  mtUnused--------------
87  mtChar, ,89,-1
88  mtUnused--------------
89  mtAnyChar,90,-1
90  mtNone,92,89
91  mtUnused--------------
92  mtChar,R,94,-1
93  mtUnused--------------
94  mtChar,E,96,-1
95  mtUnused--------------
96  mtChar,A,98,-1
97  mtUnused--------------
98  mtChar,D,100,-1
99  mtUnused--------------
100  mtChar, ,102,-1
101  mtUnused--------------
102  mtAnyChar,103,-1
103  mtNone,106,102
104  mtUnused--------------
105  mtChar, ,106,-1
106  mtNone,108,105
107  mtUnused--------------
108  mtChar,;,109,-1
109  mtTerminal,-1,-1

И заталкивается в очередь с двухсторонним доступом. И обрабатывается в такой процедуре
http://www.rsdn.ru/forum/Message.aspx?mid=607830&only=1

Автор: Serginio1
Дата: 15.04.04

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

M>>Написать нормальный List — день. Ну ещё день на совесть оттестировать и оптимизировать.
A>оптимист...
A>неделя минимум... а про тестинг это вообще на месяц затянуться может...

Если дело только в оптимизации, то нужен день. А если нужны все фичи дотнетовского листа + кучка своих, то это неделя-две писанины.

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


M>>>Это как для поиска в БД? Там же SQL, а не Regex
S>> Скульщики несчаясные. ЛОКАЛЬНЫЕ БД.

M>Ты считаешь себя таким хорошим специалистом, что пишешь собственный DB Engine? Вообще говоря, это хорошо укладывается в твой колоритный портрет
Одному сложно но вполне реально просто в стол писать не охота. А локальные вообще не проблема а над ними клиент — сервер.
А RegEx и для 1С при прямом доступе к таблицам. Скорость 50-10 МБ/сек вполне приличная, правда и уступающая поиску подстроки в 20 раз.
Осталось только девченок и мальчишек научить правописанию регулярных выражений

S> Одному сложно но вполне реально просто в стол писать не охота. А локальные вообще не проблема а над ними клиент — сервер.

Может проще использовать готовые в этом случае? Access, например?


S> А RegEx и для 1С при прямом доступе к таблицам. Скорость 50-10 МБ/сек вполне приличная, правда и уступающая поиску подстроки в 20 раз.

Хм, ты меряешь скорость регекспов в мегабайтах за секунду? Мне кажется, это спекуляция: скорость сильно зависит от данных. Сделай одну большую строку из пробелов, её регексп проскочит за мгновение.


S> Осталось только девченок и мальчишек научить правописанию регулярных выражений

Чем мне не нравятся регекспы? Тем, что их нельзя использовать сходу, с листа. Или вройся как следует и выучи, или даже не берись. Так что это плохой язык для обучения девчонок и мальчишек

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

VD>А мне не понятно почему твои всего в два раза быстрее. Нетовские с точки зрения скорости совсем бездарно написаны.
Ввел свою типизированную хэш таблицу. И на такой строке
string Pattern=@"\d+\-\d+";


MatchString IgnoreCase= 1.3404108622744
MatchString= 0.956541962735487


Net MatchString IgnoreCase= 4.6295911910592
Net MatchString = 4.10075721914377
Net MatchString IgnoreCase | Compiled)= 2.35709706121867
Net MatchString Compiled= 1.61253650952845

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

S>> Одному сложно но вполне реально просто в стол писать не охота. А локальные вообще не проблема а над ними клиент — сервер.

M>Может проще использовать готовые в этом случае? Access, например?
Спасибо. Янус медленне 1С на Access. Еще то дерьмо.


S>> А RegEx и для 1С при прямом доступе к таблицам. Скорость 50-10 МБ/сек вполне приличная, правда и уступающая поиску подстроки в 20 раз.

M>Хм, ты меряешь скорость регекспов в мегабайтах за секунду? Мне кажется, это спекуляция: скорость сильно зависит от данных. Сделай одну большую строку из пробелов, её регексп проскочит за мгновение.
Не поскочит если не укажешь, то с начала строки. Так как сравнивать по символьно придется.
Со скоростью ошибся 5-10 МБ/сек. Поиск подстроки типа IndexOf 100-200 мб/сек

S>> Осталось только девченок и мальчишек научить правописанию регулярных выражений

M>Чем мне не нравятся регекспы? Тем, что их нельзя использовать сходу, с листа. Или вройся как следует и выучи, или даже не берись. Так что это плохой язык для обучения девчонок и мальчишек
Я то врылся а вот девчонки и мальчишки .... Но юзают упрощенный синтаксис им хватает.

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


S> Там все достаточно просто. На такую строку
S>

S> string Pattern= @"(function .+\(.+\) *: *.+)|";
S>        Pattern+=@"(procedure .+\(.+\))|";
S>        Pattern+=@"(property .+read .+)";
S>        Pattern+=@" *;";

S>

Блин, может ты прочтешь правила оформления кода?

И, кстати, использовать в таких случаях += в корне не верно. Тут нужно использовать +. Тогда компилятор это все в одну строку превратит. Да и читабельнее будет.

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

M>Анакрина вообще не позволяет делать никаких предположений об оптимизациях JIT.

В мсиле понятия foreach вообще нет. Для него это блудет while с вызовом функции объекта внутри. Такие оптимизации делает компилятор Шарпа.

M>Или ты что-то недоговариваешь, или не на тот вопрос ответил

Или ты что-то не так понял.

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

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


S>> Там все достаточно просто. На такую строку
S>>

S>> string Pattern= @"(function .+\(.+\) *: *.+)|";
S>>        Pattern+=@"(procedure .+\(.+\))|";
S>>        Pattern+=@"(property .+read .+)";
S>>        Pattern+=@" *;";

S>>

VD>Блин, может ты прочтешь правила оформления кода?

VD>И, кстати, использовать в таких случаях += в корне не верно. Тут нужно использовать +. Тогда компилятор это все в одну строку превратит. Да и читабельнее будет.
Исправлюсь.
string Pattern= @"(function .+\(.+\) *: *.+)|" +
@"(procedure .+\(.+\))|" +
@"(property .+read .+)" +
@" *;";

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


VD>>И, кстати, использовать в таких случаях += в корне не верно. Тут нужно использовать +. Тогда компилятор это все в одну строку превратит. Да и читабельнее будет.
S> Исправлюсь.
S> string Pattern= @"(function .+\(.+\) *: *.+)|" +
S> @"(procedure .+\(.+\))|" +
S> @"(property .+read .+)" +
S> @" *;";

При переносе части кода инструкций и описаний на другую строку вторая и последующая строки должны быть отбиты вправо на один отступ (табуляцию).

http://rsdn.ru/article/mag/200401/codestyle.XML

Как ты будешь писать в форумах мне все равно. Но постарайся чтобы код в примерах соотвествовал правилам.