Dima TТут тюнинг всяких IsDigit() как раз повышает эту скорость.

Я не говорю, что подобный тюнинг не повышает скорость. Я говорю, что подобными оптимизациями можно пренебречь. Скажем так, если понадобится, я найду способ оптимизировать скорость и при этом IsDigit трогать не буду, потому что это самая-самая бестолковая оптимизация, которую только можно придумать. Оптимизацией это вообще нельзя никак назвать, экономия микросекунд, которую можно увидеть на миллиардах операций? Да тут кладезь того, что можно сделать в плане оптимизации, как я говорил, по-блочная многопоточная обработка, кеширование, оптимизация самого алгоритма. Ну никак не IsDigit, который не ощущается на фоне остальной обработки.

Ты когда первый раз в память гигабайт данных грузишь, что процессор у тебя в это время делает? Правильно, простаивает. А потом ты начинаешь заниматься "оптимизациями". Вот здесь и растут корни вселенского самообмана.

Dima TВобщем я к тому что разбор XML никак не сделать быстрее скорости чтения с SSD. Никакая многопоточность не поможет. Мой цикл 20061320 можно еще пооптимизировать, но схема:

Сам по себе разбор бесмысленный. Ты же что-то потом будешь делать с тем, что прочитал? Например, обрабатывать и куда-то записывать. Или вычислять. Или что-то ещё делать. Возможно твои действия потребуют нагрузки на память. И тут микрооптимизации это как зёрнышко для слона.

И какой бы диск быстрый не был, пока данные читаются с диска, ты ничего не делаешь. Вот с чём надо работать, а не бороться с ветряными мельницами.

Dima TХотя бы потому что каждый GetAttribute() помимо кода внутри еще и new string(), да и многопоточность не бесплатна, потокобезопасные классы (Concurrent...) заметно медленнее своих небезопасных аналогов.

Это если тебе надо работать с разделяемыми ресурсами. Если ты найдёшь способ максимально изолировать данные друг от друга, или ещё лучше, работать с иммутабельными структурами, то пенальти за использование многопоточности будут оправданы многократным повышением общей производительности. Тут серебряной пули нет.

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

Dima TИМХУ ты диск с сеткой на 100 Мбит путаешь.

А вот тут ты ошибаешься. Файл может быть загружен как диска, так и по сети. Файл это абстракция ОС.

Dima TКакие тут можно выводы сделать?

В том, что если тебе надо реально ускорить парсинг, то есть намного более эффективные способы это сделать и получить ощутимое ускорение, а не на жалкие не значащие миллисекунды, которые к тому же плавают от запуска к запуску (зависит от кучи факторов).

Dima TМне привычнее (x >= '0' && x <= '9') просто потому что IsDigit() нет в С/С++

Учитывая, что C# работает с UTF-16, такой способ не является корректным. Что касается C/C++, если ты там работаешь с кодировками с переменным количеством байт (а это сегодня практически абсолютный стандарт во всём мире), то такое сравнение тоже не корректно.

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

Изопропилне гони пургу - корректно и с UTF-16 и UTF-8

Посмотри реализацию IsDigit и скажи нам, почему разработчики .NET не правы, а ты прав.
И тогда поговорим о пурге.

Изопропил,

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

Изопропилно и всяческие Bengali U+09E6 .. U+09EF и т д
isDigit для них вернёт true, но int.Parse их не поймёт

Всё верно. Но надо учиться учитывать и другие культуры по возможности, даже если в конкретном случае это вроде как и не нужно.

ИзопропилДля задачи топикстартера и им подобных - адекватным как раз является c>='0'' && c<='9' , а не isDigit

Адекватным является либо IsDigit, либо своя функция IsArabicDigit, но ни как не c>='0'' && c<='9', я даже не понимаю в чём тут спор, код должен быть простым, понятным, односложным, самодокументированным. В указанном тобой утверждении можно сделать ошибку, которую очень легко не заметить. Привыкнешь писать такой код потом тяжело будет работать в адекватной команде, где за такое дают по шапке.

ИзопропилUTF-32 - всегда 4 байта на codepoint - как это влияет на классификацию?

На самом деле UCS-4, из UTF в основном используются UTF-8 и UTF-16.

Изопропилсуррогатные пары UTF-16 (0xD800—0xDFFF) никак не влияют на проверку на ascii 0..9


UCS-4 и UTF-32 в 2017 году - одно и то же

Проблема в том, что ты рассматриваешь символы как ASCII, когда работаешь с юникодом это не ASCII, так как символ может состоять из двух слов. Поэтому мимо.

UTF-32 приравняли к UTC-4, чтобы не было путанницы.

Изопропилименно поэтому isDigit и isNumber нужно использовать в полном сознании (проверка на попадание в категории Nd и No)

Нужно, не спорю.


Изопропилот тут и накрылся медным тазом "самодокументированный" код

я, например, за именем этой фукции вижу проверку на диапазон U+06F0 .. U+06F9,
хотя могу и заподозрить индоарабские U+0660 .. U+0669

Ты уже лепишь отсебятину ))

Изопропил"два слова" - суррогатные пары - исключительно особенность UTF-16 (d800..dfff)к чему ты их сюда приплёл?

Ты из какой планеты прилетел? .NET работает со строками в кодировке UTF-16. Представляешь? все исключительные особенности UTF-16 — это то, с чем приходится жить, разрабатывая под .NET

А при чём тут твои UTF-32/UCS-4 или UTF-8? Зачем вообще ты про них заговорил? К чему, для чего? В .NET используется UTF-16.


Изопропилмногобайтовый последовательности UTF-8 - первый байт 11xxxxxx, последующие - 10xxxxxxx

И чего? В .NET строках сидит UTF-16.

Изопропиля рассматриваю символы как кодовые точки юникода
кодовая точка представляется в UTF-16 суррогатной парой ("двумя словами") для плоскостей 1-16

Вообще-то ты прав, в плоскость суррогатных пар не попадают значения '0'..'9'.
А я подумал про модифицирующие сѝмволы: 0̀1̀2̀3̀4̀6̀7̀8̀9̀...