A string is composed of:
• An 8-byte object header (4-byte SyncBlock and a 4-byte type descriptor)
• An int32 field for the length of the string (this is returned by String.Length).
• An int32 field for the number of chars in the character buffer.
• The first character of the string in a System.Char.
• The rest of the string in a character buffer, terminating with a null terminator char.
… символом Юникода в диапазоне от U+0000 до U+FFFF ...
В оригинальной статье написано «character» (может для упрощения понимая?), хотя по стандарту Unicode правильно это называется «code point», т.к. там кроме «characters» есть куча управляемых непечатаемых символов. Всегда интересно было как корректно перевести «code point» на русский…
Вообще глобально любая оптимизация — это повышение скорости работы приложения в ущерб затратам на его дальнейшую поддержку. Чем больше тюнинга, тем хуже код.
Я об этом написал не один раз.
Проблема статьи в том, что автор начал оптимизировать приложение слишком рано
Я для сравнения результатов привёл лучшего конкурента на рынке, который существует более десятка лет. Результаты превосходят в разы — это провал?
Вы когда-нибудь читали про микроплатежи и истории самых богатых людей в мире? Можно провести параллель со статьёй ;)
низкоуровневой оптимизации, которые на сегодняшний день дают небольшой прирост производительности
Неверно. Всё зависит от задачи. Вы думаете люди зря придумывают SIMD (MMX, SSE, 3DNow!, AVX и пр.)? nVidia CUDA? Их используют для той же декодировки MPEG видео. И это — низкоуровневая оптимизация.
Есть различные классы задач, поэтому я всех неоднократно предупреждаю об использовании «здравого смысла» перед применением. Я уверен, что больше чем 85% приложений не требуют таких оптимизаций, но есть другие 15%, причём некоторые могут занимать очень существенную долю рынка. Взгляните на тот же Microsoft SQL Server, там всё есть: страницы базы по 8KiB, использование SIMD (таких как AVX), оптимизация со знанием про кэш-линии процессора, свой менеджер памяти и потоков, и пр. Не стоит сравнивать молоток с дрелью — эти вещи решают разные задачи, но каждую из них тоже можно улучшить по-своему.
Button : {
Visibility : "Visible",
Text : "Hello World!",
Content : [
TextBlock : {
Text : {=Button.Text}
}
]
Tooltip : [
TextBlock : {
Text : "Tool tip text goes here"
}
]
}
Подумайте с точки зрения как человек набирает код в JAML — если начинать кнопку с открывающей фигурной скобки, а тип прописывать аж в "$", то это будет сложно для Intellisense. А так набираешь 'B', в подсказке «Button», Tab — вставляет «Button: { }».
Мне тоже, стало непонятным выражение с первого взгляда, но знаете, прочитав короткую спецификацию всё становится ясно и вполне читаемым. Думаю, это дело привычки.
Когда я впервые в жизни вообще увидел код, и та было «i = i + 1» — это было жутко с моей математической точки зрения, я не мог понять как такое равенство может существовать. Познакомившись с программированием, конечно же все вопросы отпали :)
Тем не менее, эксперименты всегда хороши, даже если 95% заканчиваются неудачами. Ведь пока никто не предложит альтернативу, никто не сможет сказать что уже существуещее — лучше всего (потому что даже сравнивать не с чем).
Классно, что хоть в Json.NET добавили, а то приходится извращатся. А с атрибутами — да, порой раздрожает.
Читаю C#, думаю, как и многие :) Приходится глазами искать открывающуюся скобку :) С другой стороны, XML — слишком избыточный, но этот недостаток устраняется при комплиции XAML в BAML.
Это ясное дело. Но согласитесь, классно было бы вообще чтоб под Linux было полноценное подобие WPF для Java?
Язык есть, осталось реализовать библиотеку — кто-то ж должен начинать с каких-то примитивов :)
Ещё могу сказать, что в JSON мне не нравится по сравнению с XML:
1) нет поддержки комментариев в спецификации
2) иногда в больших файлах не видно за что отвечает закрывающая скобка, приходится трассировать глазами. В XML же видно название закрывающего тэга.
Круто было бы заставить это работать под Java (определённые платформы, типа Linux), и Android в частности! Тогда бы у вас была своя библиотека, подобная WPF, но со своим форматом и стандартами, не зависящая ни от кого.
Из видео мне показалось, что кнопки пока появляются только в определённых заранее известных местах, пока не понятно может ли изменяться поверхность в любой точке экрана. Но всё-равно круто!
Я как раз понимаю. В статье не написано, но приложение работает чуть быстрее если сервер не на локальной машине (при 1 gbit). Опять же какой сервер, где стоит, виртуальная машина или нет, пропускная способность… Поэтому ещё раз повторюсь, что в реальных условиях (даже 100 Mbit сеть), на реальном примере, мы справляемся чуть менее чем за 2 часа, когда конкурент это делает за 40.
Возвращаемся к вопросу «хоть и объективно, но бессмысленно». Статья про то, как можно сделать простые вещи сложными, но очень эффективными, а не про конкретный продукт и «реальных» условиях тестирования. Результаты оптимизации лучше показывать с минимумов воздействия внешних факторов.
Если вы предоставите статистику, что все базы в миире крупные, а не мелкие (как Adventure Works), тогда можете заявлять о «реальных условиях». Рынок разнообразный, вы не можете этого просто так знать. А мы можем строить хоть какую-то картину по нашим клиентам.
да вас бы убили за такой код :)
представьте скрипт с данными размер несколько сотен MiB. Вы будете для каждого токена делать Intern, чтобы просто сработал Object.ReferenceEquals?
Предположим SQL Server съел всю базу в память. Чем это плохо? Это наоборот хорошо для тестирования, т.к. времени чтения данных с диска нет, и можно более объективно сравнивать быстродействие двух продуктов.
Ранее в коментариях, я упоминал, что на некой реальной базе конкурент показал время 40 часов, а мы — 1 час 40 мин.
Кстати, мы тестировали сравнение реальных баз размером около 100 GiB, и получили такую картину:
конкурент — 40 часов
мы — 1 час 40 мин
Так что пример с демобазой на 200 MiB наверно не самый удачный :)
Насколько правдива и актуальна — неизвестно.
В оригинальной статье написано «character» (может для упрощения понимая?), хотя по стандарту Unicode правильно это называется «code point», т.к. там кроме «characters» есть куча управляемых непечатаемых символов. Всегда интересно было как корректно перевести «code point» на русский…
Я об этом написал не один раз.
Я для сравнения результатов привёл лучшего конкурента на рынке, который существует более десятка лет. Результаты превосходят в разы — это провал?
Вы когда-нибудь читали про микроплатежи и истории самых богатых людей в мире? Можно провести параллель со статьёй ;)
Неверно. Всё зависит от задачи. Вы думаете люди зря придумывают SIMD (MMX, SSE, 3DNow!, AVX и пр.)? nVidia CUDA? Их используют для той же декодировки MPEG видео. И это — низкоуровневая оптимизация.
Спасибо, я заметил. Я просто решил все мысли в одном коментарии написать, это был не упрёк в вашу сторону =)
Вместо этого:
Хочется в том же JSON формате видеть:
Подумайте с точки зрения как человек набирает код в JAML — если начинать кнопку с открывающей фигурной скобки, а тип прописывать аж в "$", то это будет сложно для Intellisense. А так набираешь 'B', в подсказке «Button», Tab — вставляет «Button: { }».
Когда я впервые в жизни вообще увидел код, и та было «i = i + 1» — это было жутко с моей математической точки зрения, я не мог понять как такое равенство может существовать. Познакомившись с программированием, конечно же все вопросы отпали :)
(думаю, стоит уточнить «для каких целей»)
Читаю C#, думаю, как и многие :) Приходится глазами искать открывающуюся скобку :) С другой стороны, XML — слишком избыточный, но этот недостаток устраняется при комплиции XAML в BAML.
Язык есть, осталось реализовать библиотеку — кто-то ж должен начинать с каких-то примитивов :)
1) нет поддержки комментариев в спецификации
2) иногда в больших файлах не видно за что отвечает закрывающая скобка, приходится трассировать глазами. В XML же видно название закрывающего тэга.
Возвращаемся к вопросу «хоть и объективно, но бессмысленно». Статья про то, как можно сделать простые вещи сложными, но очень эффективными, а не про конкретный продукт и «реальных» условиях тестирования. Результаты оптимизации лучше показывать с минимумов воздействия внешних факторов.
представьте скрипт с данными размер несколько сотен MiB. Вы будете для каждого токена делать Intern, чтобы просто сработал Object.ReferenceEquals?
Подсказать почему?
Ранее в коментариях, я упоминал, что на некой реальной базе конкурент показал время 40 часов, а мы — 1 час 40 мин.
конкурент — 40 часов
мы — 1 час 40 мин
Так что пример с демобазой на 200 MiB наверно не самый удачный :)