Комментарии 171
А какой смысл в переводе всего кода проекта на новый стандарт?
Начиная от использования новых возможностей языка, заканчивая нежеланием разработчиков всю жизнь возиться с языком (и костылями) двадцатилетней давности
Атом углерода вообще устроен по принципам чёрт знает скольки летней давности, но вы же не пытаетесь слезть с углеродной жизни.
Ну так вариантов-то нету, апдейтов миллиарды лет не было
А ты ж поди разбери весь этот легаси.
Уж несколько десятилетий медленно, но упорно ползём на кремний.
Атом углерода работает на bleeding edge квантовой физики. Как только выпускают обновление квантовой физики, он автоматически на неё переходит.
После того, как релизнут теорию струн, он автоматически спортируется на теорию струн (это show-stopper для теории струн).
После того, как релизнут теорию струн, он автоматически спортируется на теорию струн (это show-stopper для теории струн).
сначала бы разобраться, что такое время…
по идее нету там никаких миллиардов
по идее нету там никаких миллиардов
Попытки были.
В процессе переписывания можно кучу багов наплодить. Не всё так однозначно, всё же.
В статье мы старались описать — почему и зачем переводили.
Возможно, не вполне удачно?
И мы не ошиблись.
См. также раздел «Итоги» статьи, в частности
Возможно, не вполне удачно?
Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода.
И мы не ошиблись.
См. также раздел «Итоги» статьи, в частности
После миграции у разработчиков появилось больше возможностей. Если раньше у нас была своя доработанная версия STL и один неймспейс std, то теперь у нас в неймспейсе std находятся стандартные классы из встроенных библиотек компилятора, в неймспейсе stdx – наши, оптимизированные для наших задач строки и контейнеры, в boost – свежая версия boost. И разработчик использует те классы, которые оптимально подходят для решения его задач.
А если старый код остаётся в неизменном виде, но его изменение при поддержке и доработке производятся с применением новых возможностей? Приводит ли такой подход к каким-то затруднениям?
Да, приводит — новые версии компиляторов могут перестать (и перестают) компилировать код, написанный по старым стандартам :(
Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.
Использовать новые возможности, имея часть кода в старом стандарте, часто очень затруднительно, а иногда просто невозможно.
Не знаю, как там у 1с, но когда я переводил один свой проект (наука, консольное приложение), то переключение на c++11 привело к ошибкам при компиляции старого кода, потребовались исправления, прежде чем оно завелось. И, хуже того, если я не путаю, были места, которые компилировались, но привели к другому поведению.
С другой стороны, после того, как оно завелось, дало сразу процентов 20 прироста производительности.
С другой стороны, после того, как оно завелось, дало сразу процентов 20 прироста производительности.
Я уже 100 лет не писал на C++, но вот такой вопрос: использование char16_t не добавит головной боли пользователям, если вдруг им понадобится вбивать имена или названия на китайском, лаосском, кхмерском и прочих экзотических алфавитах?
Не добавит, у нас уже есть внедрения на языках, которые не влезают в 2 байта (китайский, вьетнамский).
И что в этом случае происходит? Нельзя ввести символ, или символ занимает два char16_t?
Символ занимает два char16_t, как и положено по стандарту unicode для utf-16.
А почему решили не переходить на UTF-8?
Видимо, по той же причине, почему и Microsoft в свое время выбрала UTF-16 для большинства внутренних представлений строк.
UTF-8 дает универсальность, а UTF-16 — скорость обработки. Для 1С скорость обработки оказалась в приоритете.
UTF-8 дает универсальность, а UTF-16 — скорость обработки. Для 1С скорость обработки оказалась в приоритете.
Универсальность дают обе кодировки, а скорость обработки латинских символов у UTF-8 выше. Сказался тут, видимо, целевой рынок. Основной массив текстов в самом 1С (и его базах) — на русском и обработка русского языка в UTF-16 и правда будет быстрее. Что двигало майкрософтом — черт его знает, точно не то, что Linux-миром.
Китайский алфавит в основном влезает в 2 байта. Больше 2 байт требует всякая экзотика, исторические виды письменности, а также эмотиконы. Вот с ними у 1С могут быть проблемы, если она не поддерживает суррогатные пары (кодирование символа в виде пары 2-байтных «символов» UTF-16).
Две вещи выглядят не логично:
1. Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
2. Если вы уже пришли к использованию компилятора GCC для Linux, то как же вас угораздило продолжить компилировать в VS2005 под Win?? Вы же могли компилировать под обе платформы используя одну версию GCC. Сколько головной боли ушло бы с упразднением третьего компилятора, 2 против 3.
1. Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
2. Если вы уже пришли к использованию компилятора GCC для Linux, то как же вас угораздило продолжить компилировать в VS2005 под Win?? Вы же могли компилировать под обе платформы используя одну версию GCC. Сколько головной боли ушло бы с упразднением третьего компилятора, 2 против 3.
1. 4 байт на один символ это слишком большой оверхид для наших приложений. У нас очень много строк живут в памяти и они могут занимать существенный процент от общего потребления
2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.
2. Visual C++ это до сих пор наилучший выбор при компиляции под Windows. GCC не обеспечивает инфраструктуру для продуктивной и комфортной работы под Windows.
1. Возможно… здесь вам точно виднее.
2. Я, разумеется, снимаю шляпу перед вашим профессионализмом, и вашего главного специалиста по С++, которого вы упомянули вначале статьи, но, по-моему, тут имеет место заблуждение…
В IDE Visual Studio (как инфраструктуре для продуктивной и комфортной работы) вы можете использовать любой компилятор, и CLang и GCC и MSVC.
Но начиная с C++11 GCC "превосходит любую доступную версию MSVC по качеству сгенерированного кода", это очевидная аксиома… Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC, как не парадоксально это бы ни звучало (мол как сам Microsoft может запаздывать со своим же компилятором!? Вот так и может и завидно регулярно.).
Но тут, разумеется, вопрос не в убеждениях. Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC, да еще для такого мега-кроссплатформенного национального проекта… как-то это не современно, на мой взгляд.
2. Я, разумеется, снимаю шляпу перед вашим профессионализмом, и вашего главного специалиста по С++, которого вы упомянули вначале статьи, но, по-моему, тут имеет место заблуждение…
В IDE Visual Studio (как инфраструктуре для продуктивной и комфортной работы) вы можете использовать любой компилятор, и CLang и GCC и MSVC.
Но начиная с C++11 GCC "превосходит любую доступную версию MSVC по качеству сгенерированного кода", это очевидная аксиома… Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC, как не парадоксально это бы ни звучало (мол как сам Microsoft может запаздывать со своим же компилятором!? Вот так и может и завидно регулярно.).
Но тут, разумеется, вопрос не в убеждениях. Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC, да еще для такого мега-кроссплатформенного национального проекта… как-то это не современно, на мой взгляд.
Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC
А где в статье сказано про веру? ;)
MSVC был выбран по объективным причинам.
Одна из основных причин — отладочная информация и отладчик. GCC не умеет генерировать полноценные pdb чтобы использовать отладчик из Visual Studio или WinDBG. И при этом не имеет отладчика под Windows. Далее, все остальные инструменты под Windows, профилировщики и прочее работают только с pdb.
То же самое относится и к clang.
Качество сгенерированного кода msvc нас устраивает более чем, для нашей кодовой базы оно даже в каких-то случаях лучше, нежели в gcc под Linux.
Вот тут ответ ваш не понятен, очень хотелось бы поподробнее.
В чем именно неполноценность генерации pdb в GCC? Если может помните на вскидку, вот прямо пример, что такого вам не выгрузил в pdb GCC 7?
Насколько я помню, время проприетарного PDB от Microsoft и форматов STABS или DWARF-2 от GNU tools прошло году эдак в 2010.
Сейчас GCC выдает стандартный PDB, а для любых сред, кроме Win, по сути дела всегда применяется отладчик GDB.
Для VisualStudio, пожалуйста, используйте WinGDB, уже стало классикой, по-моему.
У JetBrains свой встроенный GUI для GDB.
Из таблицы хорошо видно, что если закрыть глаза на CLang (тут я, увы, не специалист), то вы могли вообще для всех сред использовать одну единственную среду разработки с одним компилятором и отладчиком. Да вы просто могли поднять уровень разработки на уровень БОГ! в плане унификации))
И если в очередном C++, например, меняется реализация std::map, и единственный компилятор GCC начинает с ключом оптимизации __attribute__((optimize(«O3»))) аллоцировать память, а без ключа — нет, то это поведение становится ПРЕДСКАЗУЕМО для всех платформ, под которые вы работаете.
В чем именно неполноценность генерации pdb в GCC? Если может помните на вскидку, вот прямо пример, что такого вам не выгрузил в pdb GCC 7?
Насколько я помню, время проприетарного PDB от Microsoft и форматов STABS или DWARF-2 от GNU tools прошло году эдак в 2010.
Сейчас GCC выдает стандартный PDB, а для любых сред, кроме Win, по сути дела всегда применяется отладчик GDB.
Для VisualStudio, пожалуйста, используйте WinGDB, уже стало классикой, по-моему.
У JetBrains свой встроенный GUI для GDB.
Из таблицы хорошо видно, что если закрыть глаза на CLang (тут я, увы, не специалист), то вы могли вообще для всех сред использовать одну единственную среду разработки с одним компилятором и отладчиком. Да вы просто могли поднять уровень разработки на уровень БОГ! в плане унификации))
И если в очередном C++, например, меняется реализация std::map, и единственный компилятор GCC начинает с ключом оптимизации __attribute__((optimize(«O3»))) аллоцировать память, а без ключа — нет, то это поведение становится ПРЕДСКАЗУЕМО для всех платформ, под которые вы работаете.
PDB до сих пор закрытый формат Microsoft (без документации) и его в полном объеме не умеет генерировать ни gcc, ни clang, насколько нам известно. Хотя подвижки есть, и Microsoft выкладывала хедера по структуре PDB файлов на github.
Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.
Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
Отладчик Visual Studio является основным инструментом под Windows для нас и тут мы наталкиваемся на проблемы с поддержкой pdb.
Использовать одну и ту же среду во всех случаях — это нереально. Ведь у нас помимо Windows также есть Linux, macOS, веб-клиент, Android и iOS.
Gcc генерирует отладочную информацию в формате DWARF. Майкрософтовские инструменты, включая VisualStudio, WinDBG, DrWatson (хрень, которая показывается при падении программы и предлагает отправить отчет об ошибке) используют формат CodeView в контейнере PDB.
Хорошая новость — в clang сделали пробную версию генератора PDB, не без помощи Майкрософт, открывшей информацию по PDB. Но все это пока на ранней стадии.
Мне конечно использование gcc/mingw тоже нравится больше. Ими можно компилировать из-под линукса, из разных автоматизированных систем, итд.
Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.
Хорошая новость — в clang сделали пробную версию генератора PDB, не без помощи Майкрософт, открывшей информацию по PDB. Но все это пока на ранней стадии.
Мне конечно использование gcc/mingw тоже нравится больше. Ими можно компилировать из-под линукса, из разных автоматизированных систем, итд.
Если у вас есть много свободного времени, вы можете расковырять генератор PDB от clang и прикрутить его к gcc для решения проблемы отладки.
При такой унификации есть риск слишком сильно привязаться к особенностям конкретного компилятора. А потом, при переходе на новую версию компилятора (или на другой компилятор), могут возникнуть проблемы.
Лучше с самого начала не закладываться на особенности компилятора, не создавать технический долг, который рано или поздно придётся выплачивать.
Лучше с самого начала не закладываться на особенности компилятора, не создавать технический долг, который рано или поздно придётся выплачивать.
есть конвертер из dwarf в pdb:
github.com/rainers/cv2pdb
уже давно использую его чтобы выводить красивый стектрейс через dbghelp
github.com/rainers/cv2pdb
уже давно использую его чтобы выводить красивый стектрейс через dbghelp
Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
Использование wchar_t не означает автоматически правильную обработку строк без каких-либо усилий со стороны программиста. При работе со строками нельзя забывать, в какой кодировке они находятся.
Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.
Поэтому при прочих равных лучше уж взять тип данных, размер и семантика которого не зависит от платформы, под которую собирается код.
Символы юникода и их размер это прямо классика. Вот эталонная статья Спольски от 2003 года еще.
В 2018 году использование НЕ Юникода? это преступление против человечности… абсурд просто.
Реальный мир часто абсурден. Хотя лично я тоже убеждённый сторонник повсеместного использования Юникода для представления текстов, но есть некоторые вещи, которые Юникод представить не в состоянии. Вроде некоторых имён. Однако, это не технический вопрос об устройстве стандарта, а больше вопрос администрирования консорциума, который отказывается добавлять в стандарт редко используемые или «повторяющиеся» символы.
Также с не-Юникодом точно придётся контактировать на границах системы, за которыми бушуют океаны легаси-кодировок, будь то файлы в КОИ-8 или HTTP, который по умолчанию использует Latin-1.
Если взять Юникод, то один даже четырёхбайтовый wchar_t не способен представить все графемы таким образом, чтобы не оставить возможностей для ошибки. Как минимум, популярные ныне эмоджи могут требовать нескольких code points.
4 байта (UTF-32) как раз полностью покрывает весь Unicode. Выбор размера char влияет лишь на способ представления, но не на сами символы, поэтому в UTF-16 приходится использовать суррогатную пару. Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.
Все неприятности начинаются уже при работе непосредственно с самим Unicode.
Если опустить проблемы связанные с поддержкой новых версий стандарта, когда твоя библиотека тупо может не знать о существовании каких-нибудь новых диапазонов, то всплывает, например, проблема комбинирования символов.
С одной стороны, не так может оказаться страшно, если комбинацию нескольких символов можно с помощью алгоритмов нормализации привести к одному символу того же Unicode. Как в примере с википедии:
й й — первая буква состоит из 1 unicode символа, а вторая — из 2. (можете скопировать в блокнот, сохранить в UTF-16 и посмотреть в HEX)
Но вот уже проблемой становится, когда попадается нестандартные комбинации, типа «белая женщина-врач», являющейся комбинацией символов «женщина» (U+1F469), «модификатора — белый цвет» (U+1F3FB), «символ медицины» (U+2695) и zero-width joiner (U+200D) между ними. Такая комбинация вообще не декларируется стандартом и эмодзи такого в Unicode нет по понятным причинам.
Более того, использование UTF-32 как раз лишает программиста головной боли связанной с обработкой текста, как набора Unicode символов, поскольку в таком случае у тебя в памяти лежит массив char'ов, где каждый char — это конкретный символ Unicode.
Вот именно что не решает. Как раз из-за комбинаций, образующих одну визуальную единицу. Когда я выделяю в текстовом поле «⚕️» — а что вы видите в своём браузере? что хабраредактор сделал с моим текстом? — и копирую этот символ, то обычно ожидается, что скопируются все четыре code points, из которых он состоит:
- U+1F469 WOMAN
- U+200D ZERO WIDTH JOINER
- U+2695 STAFF OF AESCULAPIUS
- U+FE0F VARIATION SELECTOR-16
Не один wchar_t, а четыре. Откуда-то текстовое поле должно знать, что в этом конкретном случае надо поступать именно так. Здесь, правда, ситуация немного натянутая: текстовое поле как бы занимается отображением текста, так что оно-то и так в курсе, сколько визуального места занимает каждая последовательность байтов, кодирующая тот или иной текст.
Программист здесь может ошибиться, например, в операции «взять первый символ» в строке, реализовав её как string[0]. Если используется UTF-8, то эта операция вернёт некорректный UTF-8 текст из одного байта 0xF0. Если используется UTF-32, то эта операция даст технически корректный текст, но будет семантически неверной, так как потеряет все пришлёпнутые сзади модификаторы.
Юникод — это фундаментально кодировка с переменной длиной графем. Работать с текстом в основном надо либо на визуальном уровне графем (иногда их частей) для отображения и редактирования, либо на уровне байтов для передачи и хранения. Формат представления никак не помогает правильно работать с графемами: что в UTF-32, что в UTF-8 надо знать отдельные правила их обработки. В любом случае для обработки графем придётся жить с тем, что один условный char в массиве не соответствует одной графеме.
Для передачи и хранения вообще удобнее работать как раз с массивом байтов, так как длина массива байтов в байтах и порядок байтов в байте не зависит от операционной системы, архитектуры процессора и компилятора. С этой точки зрения UTF-8 является идеальным форматом. У UTF-16 есть преимущество в компактности для текстов на языках, символы которых в UTF-8 кодируются тремя байтами. (Плюс, есть исторически сложившиеся API, принимающие именно UTF-16.) У UTF-32… есть много лишнего места, разве что. Это удобное промежуточное представление для преобразований между форматами, но для хранения и обработки UTF-32 подходит не очень.
Насчет экспертизы UTF-32 — полностью согласен. Не понимаю, зачем тратить в два раза больше места, если можно все кодировать в UTF-16. UTF-8 скорее всего смысла не имеет именно потому что кириллица в нем не может быть отражена одим байтом…
Я и не говорю, что UTF-32 решает проблему вывода графем, но то, что с ним не легче работать, чем с UTF-16 или UTF-8…
Юникод — это же в первую очередь таблица «индекс — символ», а проблема вывода лежит в области обработки массива таких индексов.
Согласитесь, что проще оперировать голыми int'ами, как в случае той же «женщины-врача» — это по сути конкретная последовательность {0x1F469, 0x200D, 0x2695, 0x200D, 0xFE0F}. При обработке, в таком случае, нас ждёт всего одна операция — поиск такой последовательности в массиве. В случае же работы с каким-нибудь UTF-8 перед тем, как искать последовательность потребуется перекодировать данные для получения опять же набора int'ов.
Только не подумайте, что я топлю за использование 4 байтов. Накладные расходы на хранение таких данных, особенно при работе с большим количеством строк, как тут — это слишком.
Юникод — это же в первую очередь таблица «индекс — символ», а проблема вывода лежит в области обработки массива таких индексов.
Согласитесь, что проще оперировать голыми int'ами, как в случае той же «женщины-врача» — это по сути конкретная последовательность {0x1F469, 0x200D, 0x2695, 0x200D, 0xFE0F}. При обработке, в таком случае, нас ждёт всего одна операция — поиск такой последовательности в массиве. В случае же работы с каким-нибудь UTF-8 перед тем, как искать последовательность потребуется перекодировать данные для получения опять же набора int'ов.
Только не подумайте, что я топлю за использование 4 байтов. Накладные расходы на хранение таких данных, особенно при работе с большим количеством строк, как тут — это слишком.
В случае UTF-8 поиск и замена выполняется настолько же просто. Только у вас массив байтов и искать там надо последовательность {0xF0, 0x9F, 0x91, 0xA9, 0xE2, 0x80, 0x8D, 0xE2, 0x9A, 0x95, 0xE2, 0x80, 0x8D, 0xEF, 0xB8, 0x8F}. Что так искать последовательность, что эдак.
Только когда приходит время отправлять текст в сеть или записывать его на диск — а они работают только с байтами — в случае UTF-32 приходится выбирать, записать U+1F469 как {0x00, 0x01, 0xF4, 0x69} или как {0x69, 0xF4, 0x01, 0x00}, аналогично для UTF-16 — {0xD8, 0x3D, 0xDC, 0x69} или {0x3D, 0xD8, 0x69, 0xDC}, тогда как в UTF-8 вариант только один: {0xF0, 0x9F, 0x91, 0xA9}.
Только когда приходит время отправлять текст в сеть или записывать его на диск — а они работают только с байтами — в случае UTF-32 приходится выбирать, записать U+1F469 как {0x00, 0x01, 0xF4, 0x69} или как {0x69, 0xF4, 0x01, 0x00}, аналогично для UTF-16 — {0xD8, 0x3D, 0xDC, 0x69} или {0x3D, 0xD8, 0x69, 0xDC}, тогда как в UTF-8 вариант только один: {0xF0, 0x9F, 0x91, 0xA9}.
Ну вот, вместо понятной последовательности индексов используем массив «каких-то» байт. А ведь при выводе помимо такой замены проводится ещё и нормализация, которая проводится через преобразование в UTF-32 и обратно. Во всяком случае в тех реализациях, что я видел — это так.
А ещё можно вот какой финт сделать в UTF-32:
1) Нормализуем.
2) Заменяем все нестандартные последовательности на свои индексы из пользовательских диапазонов.
3) Теперь с таким массивом действительно можно работать, как с массивом визуальных единиц не боясь повредить данные.
И я понимаю, что проблема порядка байт остаётся, но я же говорю не о проблеме хранения и передачи, а об удобстве обработки таких данных.
А ещё можно вот какой финт сделать в UTF-32:
1) Нормализуем.
2) Заменяем все нестандартные последовательности на свои индексы из пользовательских диапазонов.
3) Теперь с таким массивом действительно можно работать, как с массивом визуальных единиц не боясь повредить данные.
И я понимаю, что проблема порядка байт остаётся, но я же говорю не о проблеме хранения и передачи, а об удобстве обработки таких данных.
С точки зрения алгоритма поиска между последовательностью индексов и последовательностью байтов разницы особой нет же. Оба вида последовательностей получаются из других строк текста, а не составляются вручную программистом. И для ренормализации строки после замены достаточно затронуть только несколько соседних символов, всю строку в UTF-32 преобразовывать не надо.
Идея с использованием неиспользуемых значений в UTF-32 интересная. В 4 байта же действительно можно разместить ещё 4096 дополнительных Юникодов, если использовать лишние битики. Не знаю, будет ли какой-то существенный выигрыш в производительности от такой замены и нестандартного представления, но идея однозначно интересная! Спасибо.
Идея с использованием неиспользуемых значений в UTF-32 интересная. В 4 байта же действительно можно разместить ещё 4096 дополнительных Юникодов, если использовать лишние битики. Не знаю, будет ли какой-то существенный выигрыш в производительности от такой замены и нестандартного представления, но идея однозначно интересная! Спасибо.
По поводу второго пункта — очень странная идея использовать gcc везде, я бы еще понял, если бы вы clang предложили, но gcc после ухода с него андроида постепенно уходит в легаси. Симбиан и Маемо в 2018 году никому не нужны, ios — clang, андроид — clang, win — msvc или clang, linux — gcc или clang.
Ну и под вин ничего лучше msvc все же нет, несмотря на усилия clang (а не gcc) в этом плане. Как и лучше IDE, чем Visual Studio, при всем уважении к CLion. И по части стандартов msvc сильно подтянулся, хотя до clang не дотягивает.
Если рассматривать микропроцессоры как еще одну платформу, а это по истине гигантский рынок, то там все-таки преобладает GCC и перемен в строну CLang не ожидается. А вот переход на более изящный синтаксис C++ имеется, чипы растут в производительности и там, где раньше приходилось виртуозить на Си, периодически переходя на Асм, можно уже безболезненно использовать стандартные контейнеры из std.
Т.е. в плане унификации, сейчас GCC все же более удобен.
СLang — будем посмотреть))
Т.е. в плане унификации, сейчас GCC все же более удобен.
СLang — будем посмотреть))
Ну так как 1C на микроконтроллерах не работает и вряд ли будет, то это к теме поста отношения не имеет. Соглашусь, что в embedded gcc может быть и сильнее — не сильно погружен, не могу всерьез комментировать — но игнорировать iOS и Android тоже нельзя — а там gcc (уже) нет. Так что с тезисом про унификацию согласиться не могу.
При этом ее полезность тоже не стоит переоценивать — у нас в компании легко собирается продукт под gcc разных версий, clang разных версий и MSVC разных версий — наверное, 6 вариантов суммарно — и не могу сказать, чтобы это было как-то так уж сложно сейчас. Основные проблемы в АПИ платформы, а тут никакой компилятор не поможет.
И еще один момент, многие наработки из Boost для работы с контейнерами перекочевывают в C++17. Вам имеет смысл потом снова проверить аллокацию памяти для std::map|set, возможно проблема будет пофиксина (как минимум в GCC) и удастся снова вернуться к стандартным контейнерам.
Спасибо. Стало понятнее что случилось со стабильностью релизов Платформы после 8.3.10 (так пока и сидим на нем из-за критичного бага со внешними источниками в режиме совместимости 8.2.13).
Даже демо платформы ( platform.demo.1c.ru/demo83 ) до сих пор не переведено на типа актуальную 8.3.13, а остается на 8.3.12.
Остается надеяться, что 1С в ближайшее время таки справится с проблемами, связанными с таким серьезным переходом.
Даже демо платформы ( platform.demo.1c.ru/demo83 ) до сих пор не переведено на типа актуальную 8.3.13, а остается на 8.3.12.
Остается надеяться, что 1С в ближайшее время таки справится с проблемами, связанными с таким серьезным переходом.
Зря человеку карму подпортили. Мы недавно пробовали перейти на 8.3.13 (конфигурации — управляемые приложения). Поплевались, психанули и откатились на 8.3.11.3034. Динамические списки ведут себя неадекватно, колонки съезжают. Веб-клиент (понимаю, что написан не на С++) постоянно ошибки выдает.
А в каких именно конфигурациях проблемы?
В типовых или в самописных?
В типовых или в самописных?
Самостоятельно разработанные конфигурации. Но по стандартам и методикам 1С, с нормализованной схемой БД.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
Самостоятельно разработанные конфигурации.
Но по стандартам и методикам 1С,
При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
с нормализованной схемой БД.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
Простой пример, динамический список ведет себя непредсказуемо как элемент формы — при клике позиционирует выбранную строку всегда посередине. Запрос дин. списка очень простой (выборка из документа даты, номера, автора). 95% процентов пользователей работают через веб-клиент. Если действительно интересны выявленные проблемы, могу еще раз провести тесты на 8.3.13 и передать результаты.
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
При выходе новых версий платформы 1С публикует изменения стандартов.
Так что конфигурации может потребоваться модифицировать для работоспособности в новых версиях платформы.
Мы это учитывает.
А это про что, можете пояснить?
В 1С объекты БД явно не создаются, это делает платформа, и в этот механизм вмешиваться не рекомендуется.
В работу платформы на уровне SQL не лезем. Чтобы писать запросы, нужно понимать что из себя представляет БД 1С. А мы знаем, что это таблицы в СУБД. Поэтому при проектировании структуры объектов конфигурации оперируем понятием «таблица», но с использованием тонкостей 1С (периодичность регистров сведений, регистры остатков, оборотов и т.п.). Соответственно, приводим схему данных в такое состояние, когда у нас нету избыточности. Или нехватки данных (статья на ИТС про самодостаточность регистров).
Если не сложно — сделайте пожалуйста.
Воспроизведутся проблемы — шлите конфигурацию, будем чинить.
Хорошо. Результаты лучше в личку?
Как вообще в проекте такой сложности и тяжести можно додуматься использовать стандартные контейнеры и потоки, которые мягко говоря, не оптимизированы? Ну разве что легаси. Но у меня бы в первую очередь это бы вызвало вопросы к коду, раз уж не жаль 6 месяцев работы сеньора на перевод на стандарт.
Таки если вы читали статью — в них-то и узкое горлышко. Если у вас есть лишние люди, конечно, можно в проектах такого уровня зависеть от чужих либ в таких базовых вещах, но выглядит это странно. Я, разумеется, не стал бы переписывать библиотеку работы со звуком или чтения каких-то мудреных чужих форматов, но в игровых проектах я столько «изящной архитектуры и изящных конструкций» насмотрелся, которые надо оптимизировать тупо через массивы или переопределять new, чтобы хоть как-то работало. Так что перекопать базу и твердо на ней стоять — маст хэф. Праада на сях давно не писал, может std и правда стало мастерписом, но в мое время это был странный перешаблонированный и мешающий отладке монстр, к тому же скорее академический, чем для реального использования в хевилоаде.
Говорю же, давно не писал на сях и более ко мне stl:: не применим, к тому же давно потерял веру в человечество, а после бардака с многократным переворотом парадигмы мультипоточного кода у мелкософта, и вовсе стараюсь изо всех сил, где это аозможно, обходить зависимости от чужого кода или протоколов, если у проекта запланировано жизни более 2 лет.
Вообще, это наверное, с молодостью проходит — восторженныая радость при слежении за обновлениями и переворотом в технологиях. Со временем обновления ОС, IDE, библиотек и сервисов вызывают лишь чувство досады, иногда тревоги, иногда — испанского стыда, но больше просто легкое раздражение, что опять придетмя ковырять то, что давно в продакшне.
Вообще, это наверное, с молодостью проходит — восторженныая радость при слежении за обновлениями и переворотом в технологиях. Со временем обновления ОС, IDE, библиотек и сервисов вызывают лишь чувство досады, иногда тревоги, иногда — испанского стыда, но больше просто легкое раздражение, что опять придетмя ковырять то, что давно в продакшне.
Это неверное утверждение, особенно в отношении контейнеров, для чего-то другого — возможно.
Как раз сейчас в С++ контейнеры особенно модернизируются. Например, для того, чтобы эффективно работала в С++17 вот какая изящная конструкция множественной итерации.
Сейчас вы вынужденны применять для этой задачи все тот же сторонний Boost (реализация которого иногда тяжеловата, т.к. он опирается на существующие контейнеры, создавая над ними обертки)
И, кстати, для окончательного отказа от указателей, в пользу новых интеллектуальных указателей или модернизированных ссылок (С++17) также придется оптимизировать/переписать реализацию всего, где происходят итерации по массивам.
Как раз сейчас в С++ контейнеры особенно модернизируются. Например, для того, чтобы эффективно работала в С++17 вот какая изящная конструкция множественной итерации.
for (auto [x,y,z] : zip( xs, ys, zs )) {
// ...
}Сейчас вы вынужденны применять для этой задачи все тот же сторонний Boost (реализация которого иногда тяжеловата, т.к. он опирается на существующие контейнеры, создавая над ними обертки)
for(auto&& t : zip_range(contA, contB)) {
t.get<0>(items) = t.get<1>(items);
}И, кстати, для окончательного отказа от указателей, в пользу новых интеллектуальных указателей или модернизированных ссылок (С++17) также придется оптимизировать/переписать реализацию всего, где происходят итерации по массивам.
А обновленные шаблоны native ВК в связи с переходом на новый стандарт стоит ждать?
В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало? Победили все первоначальные проблемы?
В итоге-то новая версия стала работать быстрее или медленнее, что с памятью стало?
Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.
И потребляет при этом не больше памяти, чем старая.
Коллеги на проф. форуме неоднократно описывали обратное. Например:
partners.v8.1c.ru/forum/t/1723890/m/1747082
Новая версия платформы на типовых сценариях работает не медленнее старой.
И потребляет при этом не больше памяти, чем старая.
Перед релизом мы тестируем на типовых сценариях.
Когда нам присылают сценарии, на которых есть деградация по производительности/памяти — мы, по мере возможности, фиксим платформу и исправляем ситуацию.
Все возможные сценарии, как вы понимаете, перебрать в принципе невозможно.
И попутно угробили работоспособность конфигурации 1С: ЖКХ. И, вероятно, не только ее. Молодцы, что сказать. Про общую скорость работы я вообще промолчу, она все хуже и хуже.
И попутно угробили работоспособность конфигурации 1С: ЖКХ
А что случилось с 1С:ЖКХ на новой платформе?
Про общую скорость работы я вообще промолчу, она все хуже и хуже
На каких сценариях она все хуже и хуже?
1. Функционал связанный с подъездами и квартирами (может еще где, я не выискивал) полностью отвалился.
Ошибки:
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EObjectNotFound) Object «СЗК_ЗащищеннаяОбработка» is not found
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EBadFileFormat) Bad file format
Вылетает при попытке доступа к Зданиям при создании или редактировании.
2. Бухгалтера с каждым новым обновлением платформы поднимают вонь что так работать невозможно, что тормозит ужасно. Мне сравнивать не с чем, я так, по сути немного помогаю по мелочи, но и сам тыкаясь по разделам ощущаю что оно довольно медленно ворочается даже на почти пустой базе под ЖКХ, особенно при сохранении данных. При этом сервер на котором стоит платформа, БД и работают тонкие клиенты даже не напрягается. БД — SQL Server.
Ошибки:
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EObjectNotFound) Object «СЗК_ЗащищеннаяОбработка» is not found
{ВнешняяОбработка.МенеджерОбъектов.МодульОбъекта(9)}: (EBadFileFormat) Bad file format
Вылетает при попытке доступа к Зданиям при создании или редактировании.
2. Бухгалтера с каждым новым обновлением платформы поднимают вонь что так работать невозможно, что тормозит ужасно. Мне сравнивать не с чем, я так, по сути немного помогаю по мелочи, но и сам тыкаясь по разделам ощущаю что оно довольно медленно ворочается даже на почти пустой базе под ЖКХ, особенно при сохранении данных. При этом сервер на котором стоит платформа, БД и работают тонкие клиенты даже не напрягается. БД — SQL Server.
А можете ссылку кинуть на конкретную конфигурацию на сайте производителя конфигурации?
Это что-нибудь из вот этого комплекса?
Или речь совсем о другом?
Конфигурация, насколько понимаю, не от 1С.
Это что-нибудь из вот этого комплекса?
Или речь совсем о другом?
Конфигурация, насколько понимаю, не от 1С.
Вот эта: vgkh.ru/jsk/jkh/capabilities.php
Перестала работать после обновления платформы до последней версии. Не помню, правда, какая то версия была. Сами разработчики конфигурации говорят что работает стабильно на 12й версии, а 13я глючная (это с их же слов). При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
Перестала работать после обновления платформы до последней версии. Не помню, правда, какая то версия была. Сами разработчики конфигурации говорят что работает стабильно на 12й версии, а 13я глючная (это с их же слов). При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
Вот эта: vgkh.ru/jsk/jkh/capabilities.php
Тут вопросы к разработчикам конфигурации.
Они декларировали совместимость конфигурации с той платформой, на которой появляются проблемы?
При этом откатиться назад нельзя т.к. станут несовместимы какие-то другие конфигурации.
Насколько знаю — можно поставить разные версии платформы даже на один сервер и разные конфигурации запускать под разными версиями платформы. Или у вас не та ситуация?
Да кто ж его разберет теперь декларировали или нет. Проблема в том, что новый функционал по хорошему не должен убивать уже существующий как произошло в данном случае. И ладно бы версии были сильно разными, так нет же. С версией 2х-месячной давности оно работало, а с версией 3-4х недельной давности уже нет. Я не могу сказать какая была до этого версия, но знаю что обновления платформы ставятся подрядчиками оперативно. На сколько помню апдейт был в августе (на нем работало) и в октябре (уже не работает).
Вариант с разными версиями прекрасен во всей своей костыльности.
Все это звучит прямо как «мы тут что-то сломали, но это не наша проблема».
Вот реально платишь хренову тучу денег за гемор с лицензиями, с обновлениями, с сопровождением, с переносом данных и т.д. и т.п.
Я к этому всему имею немного косвенное отношение т.к. моя задача была перенести данные из существующей системы в 1С и потом это все интегрировать в кабинет пользователя. И понеслось…
Вариант с разными версиями прекрасен во всей своей костыльности.
Все это звучит прямо как «мы тут что-то сломали, но это не наша проблема».
Вот реально платишь хренову тучу денег за гемор с лицензиями, с обновлениями, с сопровождением, с переносом данных и т.д. и т.п.
Я к этому всему имею немного косвенное отношение т.к. моя задача была перенести данные из существующей системы в 1С и потом это все интегрировать в кабинет пользователя. И понеслось…
Да кто ж его разберет теперь декларировали или нетДак тот, кто обновлял — тот и разберёт)
Где туча денег? Если не обновлять конфигурации, то можно ничего не платить. Если обновлять то можно покупать итс.техно за 12500 в год. Это примерно 1 МРОТ. А для базовых версий обновления бесплатны. Вы уверены, что это туча денег?
Я про весь комплект включая лицензии на пользователей, конфигурацию, итс на платформу, итс на конфигурацию, лицензию на SQL Server. Еще приходится оплачивать услуги подрядчиков чтобы не иметь головняка с процессом обновления.
Про не обновлять конфигурацию, я надеюсь, вы пошутили… Конечно, можно в целях крайней экономии к этому варианту прийти, но тогда уж проще и дешевле использовать аналогичные продукты, если такие имеются на рынке.
Про не обновлять конфигурацию, я надеюсь, вы пошутили… Конечно, можно в целях крайней экономии к этому варианту прийти, но тогда уж проще и дешевле использовать аналогичные продукты, если такие имеются на рынке.
ИТС на локальную сеть нужен один. Остальные лицензии — это разовые затраты, компьютер же бесплатно никто не дает? Обновление типовых конфигураций с появлением расширений можно доверить роботу, да расширения бывают отваливаются, но для меня это не критично. Не обновляться вообще? Легко на вмененке или упрощенке.
Затраты на переписывания кода для получения новых проблем окупились?
Я так понял что основная проблема была «угловые скобки у нас были разделены пробелами». Зато теперь модно, молодёжно:
— увеличили потребление памяти (всеобщий тренд)
— стало требовать свежее железо для сборки (наконец-то можно обновить пакр)
— winxp в пролёте
— теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
— тесты стали тоже требовать больше ресурсов
— функционал тот же но исполняемый файл солиднее и капризней
— зато теперь можно использовать свежий boost (а не эти костыли)
«Небыло печали купила баба порося»: Кодовая база стала меньше? Время сборки уменьшилось? Время на устранение багов сократилось или стало более предсказуемым? Или просто доработать чтобы компилировалось и проходило тесты? В чем огромный плюс проведённо титанической работы особенно для клиента?
В целом ваш высококвалифицированный разработчик просто красавчик. Его плюсы затмевают ваши минусы. Предлагаю повысить ему зарплату.
Я так понял что основная проблема была «угловые скобки у нас были разделены пробелами». Зато теперь модно, молодёжно:
— увеличили потребление памяти (всеобщий тренд)
— стало требовать свежее железо для сборки (наконец-то можно обновить пакр)
— winxp в пролёте
— теперь нужны более дорогие специалисты для поддержки кодовой базы (а то лезут тут всякие)
— тесты стали тоже требовать больше ресурсов
— функционал тот же но исполняемый файл солиднее и капризней
— зато теперь можно использовать свежий boost (а не эти костыли)
«Небыло печали купила баба порося»: Кодовая база стала меньше? Время сборки уменьшилось? Время на устранение багов сократилось или стало более предсказуемым? Или просто доработать чтобы компилировалось и проходило тесты? В чем огромный плюс проведённо титанической работы особенно для клиента?
В целом ваш высококвалифицированный разработчик просто красавчик. Его плюсы затмевают ваши минусы. Предлагаю повысить ему зарплату.
MSVC прекрасно компилирует бинари под xp вне зависимости от стандарта языка, нужно просто соответствующий тулчейн выбрать.Собирать то он собирает, но работать не будет. И никто с этим заморачиваться не захочет.
это не «более дешевый» специалист, это просто плохой специалистДело не в плохой/хороший. Сравните объём ненужного в новом стандарте, объём знаний который надо запихать в студента за ограниченное время. Думаете качество знаний в таких условиях тоже будет расти? Так что затраты на обучение новых специалистов будут непрерывно расти пока не придёт понимание что дорогонах.
Сделали бы уже новый С++ явно не совместимым со старым вместо того что-бы регулярно собирается и выдумывать как еще фишку прикрутить к 38 летнему старью, оставив старьём.
Ведь по факту получаем что каждый раз нужна работа по переводу кода на новый стандарт C++ разве это не странно при наличии обратной совместимости?
Насчёт выкинуть с++ на свалку истории — полностью согласен.
сейчас набежит школота и скажет, что я ниосилятор. Да, признаю, просто невозможно успевать за развитием с++.
Просто есть баланс: латать по-чуть-чуть и прямо сейчас (получают маленькие проблемы, которые потихоньку можно править). Или переписать все, например, на той же Джава. И сколько человеко-часов единомоментно тогда придется потратить? К тому же, простого пути миграции с одной экосистемы языка на другую нет. Поэтому технический долг нарастает.
сейчас набежит школота и скажет, что я ниосилятор. Да, признаю, просто невозможно успевать за развитием с++.
Просто есть баланс: латать по-чуть-чуть и прямо сейчас (получают маленькие проблемы, которые потихоньку можно править). Или переписать все, например, на той же Джава. И сколько человеко-часов единомоментно тогда придется потратить? К тому же, простого пути миграции с одной экосистемы языка на другую нет. Поэтому технический долг нарастает.
А почему Вы считаете std::launder ненужным?
std::launder это очередной костыль, который помогает бороться очередным UB, который вызван новым стандартом, который позволяет компилятору использовать не обоснованную логику, которая используется при оптимизации в тех ситуациях где она нафиг не нужна (в доме который построил Страуструп)
Вообще это печально постоянно жертвуют здравым смыслом ради непонятно чего. И потом тыкают лозунгом мы не хотим платить за то что не используем. Зато потом за это платят все остальные.
Вообще это печально постоянно жертвуют здравым смыслом ради непонятно чего. И потом тыкают лозунгом мы не хотим платить за то что не используем. Зато потом за это платят все остальные.
>Собирать то он собирает, но работать не будет. И никто с этим заморачиваться не захочет.
И пример ситуации, когда v141_xp генерирует нерабочий бинарь, вы конечно привести сможете.
И пример ситуации, когда v141_xp генерирует нерабочий бинарь, вы конечно привести сможете.
Например 1, [2](http://qaru.site/questions/847528/vs2017-and-missing-api-ms-win-core-rtlsupport-l1-2-0dll-on-win7xp), 3Чисто из любопытства, зачем вы заходите на помоечные сайты типа qaru?
Все материалы там взяты cо StackOverflow и подвергнуты автоматическому переводу.
К примеру, вот оригинал второй ссылки на SO: https://stackoverflow.com/questions/45745336/vs2017-and-missing-api-ms-win-core-rtlsupport-l1-2-0-dll-on-win7-xp
1. Согласен, сходу не работает.
2. Косяк разработчика: почему-то
— он взял не те библиотеки (onecore вместо x86)
— не воспользовался статической линковкой
— не воспользовался Redist
3. Проблема не сколько с MSVC, сколько с Windows SDK.
Работа семейства функций _stat исправлена ещё в Universal C Runtime 10.0.10586 (плюс ещё одна причина использовать Redist, вместо того, чтобы таскать всю эту пачку из 40+ библиотек с собой)
2. Косяк разработчика: почему-то
— он взял не те библиотеки (onecore вместо x86)
— не воспользовался статической линковкой
— не воспользовался Redist
3. Проблема не сколько с MSVC, сколько с Windows SDK.
Работа семейства функций _stat исправлена ещё в Universal C Runtime 10.0.10586 (плюс ещё одна причина использовать Redist, вместо того, чтобы таскать всю эту пачку из 40+ библиотек с собой)
интересная статья. Спасибо. Вопросы
- делали ли код-фриз на время переноса? Если нет, то не было потом проблем со слиянием багфиксов предыдущих релизов и крайней версии, перенесенной на новый тулинг С++?
- Используете ли техники статического анализа кода? Например, продукт PVS Studio www.viva64.com/ru/pvs-studio
- Не появилось ли проблем у пользователей при миграции между версиями? Т.к. бинарные данные изменили формат/layout или еще что-нибудь
Спасибо, мы старались!
1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).
2. Конечно используем на постоянной основе. PVS Studio основной инструмент.
3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
1. Код-фриз не делали, работы над стволом и новым стандартом велись параллельно. После обновления, в некоторых случаях, конечно, есть проблемы переноса исправлений в старые версии платформы (без поддержки стандарта C++14).
2. Конечно используем на постоянной основе. PVS Studio основной инструмент.
3. Формат бинарных данных затронут не был. Только алгоритмы обработки. Так что проблем с этим не было.
Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.
Любопытно. Если бы у Вас не было альтернативной реализации строки под рукой, то Вы бы никогда и не провели такой тест, верно?
Если это только отдельные места, где производительность просела до 20-30%, то может надо было эти места оптимизировать или даже (крамола!) кое-где забить на это? Всё-таки отказ от стандартной строки это серьёзный шаг.
Всё-таки отказ от стандартной строки это серьёзный шаг.
Мы этот шаг сделали довольно давно :)
По моему опыту, любые проекты, много работающие со строками, используют свою реализацию строк, по ряду причин, не последняя из которых — быстродействие. Из того что видел сам — платформы двух больших западных ERP (это даже частично сам писал), и вот еще 1С. Из того, про что слышал — уже упомянутый Facebook, например.
А Вы не могли бы немного подробнее рассказать, на чём именно теряется быстродействие и память в Вашем случае? Конкретно интересует следующее: теоретически семантика перемещения при правильном применении в большинстве случаев должна свести на нет преимущества от COW. Но это сработает только если переписать код в соответствующем стиле. Можно предположить что переписывать код было слишком трудоёмко и поэтому было принято решение вернуться обратно к реализации на COW. Но возможно решающую роль сыграла оптимизация хранения коротких строк? Расскажите подробней, пожалуйста.
А когда обновления нормально ставится будут? А то достало уже стандартную базу обновлять через конфигуратор. Обновления выходят чуть ли не раз в месяц. Оно еще и адски долго запускается.
Когда запуск ускорите? А то получается, как с MS Offise и LibreOffice. Первый запускается вечность, а второй на той же конфигурации раза в три быстрее при первом запуске и раз в 20 при повторном. Только вот у вас к сожалению конкурентов нет.
Когда запуск ускорите? А то получается, как с MS Offise и LibreOffice. Первый запускается вечность, а второй на той же конфигурации раза в три быстрее при первом запуске и раз в 20 при повторном. Только вот у вас к сожалению конкурентов нет.
Пока автор отвечает, предположу что исторически так сложилось. Изначально основной платформой был Виндос, поэтому когда-то был выбран UCS-16. Сегодня переходить на другую кодировку мучительно больно — ведь нужно сохранять совместимость с предыдущими версиями, при этом заранее оценить величину выигрыша/проигрыша затруднительно.
Для преимущественно англоязычных данных UTF-8 имеет смысл, в нашем случае профит будет небольшой.
И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
И потом, переход на UTF-8 может оказаться несравнимо тяжелее, нежели переход на новый стандарт, ситуацию нужно тщательно анализировать, учесть все возможные выигрыши и потери.
10 миллионов строк
Это безумно большая цифра для программного кода, с таким объёмом он уже должен обрести собственное сознание…
Возможно имелось в виду общее количество строк?
Вместе с пустыми хидерами со стандартной шапкой, отсутствием кода и смысла. Почти любой проект содержит 99% подобного мусора, кроме самых мелких — для них ещё всё впереди.
В этом случае можно достичь большей оптимизации — просто удалив воду. Алгоритм при этом не пострадает, я уверен в этом.
Это безумно большая цифра для программного кода, с таким объёмом он уже должен обрести собственное сознание…
Возможно имелось в виду общее количество строк?
Вместе с пустыми хидерами со стандартной шапкой, отсутствием кода и смысла. Почти любой проект содержит 99% подобного мусора, кроме самых мелких — для них ещё всё впереди.
В этом случае можно достичь большей оптимизации — просто удалив воду. Алгоритм при этом не пострадает, я уверен в этом.
Да, мне тоже интересно, откуда в одинэске набралось столько кода.
Это безумно большая цифра для программного кода
Чем же эта цифра пугает. 10 миллионов строк. В половине строк по одному символу ({ и }), еще четверть строк (если не больше) — комментарии и т.д.
Посмотрите на код Firefox или что-то в этом духе. А вы говорите "безумно большая цифра".
А вся статья изложена в заголовке:
Как мы перевели 10 миллионов строк кода C++ на стандарт C++14 (а потом и на C++17)
Судя по инфографике — 10 миллионов не так уж и много
www.visualcapitalist.com/millions-lines-of-code
www.visualcapitalist.com/millions-lines-of-code
не хотите слезть со своих бинарных протоколов, зашитых на размер wchar_t, на кросплатформенные (protobuf, например)?
Вопрос от чайника. Правильно ли я понял, что теперь фичи новых Xeon/Core будут наконец задействованы? Или флаги компиляции так и остались на «Pentium-4»?
Да, кстати, интересный вопрос.
Используются ли дополнительные инструкции процессора в коде, или вся надежда на компилятор, что он верно сам увидит и соптимизирует.
Используются ли дополнительные инструкции процессора в коде, или вся надежда на компилятор, что он верно сам увидит и соптимизирует.
К сожалению, мы не можем так просто задействовать фичи новых процессоров у себя в платформе. Некоторое время назад мы пытались банально включить поддержку SSE2 при компиляции 32-битной платформы (в x64 процессорах она уже есть по умолчанию) и сразу получили несколько проблем от внедренцев, т.к. у клиентов до сих пор используются компьютеры, не поддерживающие SSE2.
Печально. Так и будем гоняться по «помойкам» за старыми Xeon На 3.2 ГГц для серверов 1С?
Вариант выпуска нескольких наборов бинарников, условно «под старые процессоры» / «под новые процессоры» хотя бы для Windows платформы не рассматривался?
Вариант выпуска нескольких наборов бинарников, условно «под старые процессоры» / «под новые процессоры» хотя бы для Windows платформы не рассматривался?
Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.
По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.
По поводу двух редакций — сейчас фактически так и есть, 32-битная платформа для старого железа и ОС, 64-битная платформа — для современных. В том числе для этого мы сделали 64-битный клиент и Конфигуратор.
Речь шла о клиентских компьютерах и, соответственно, процессорах. С серверными такой проблемы нет.— с какого момента с серверными бинарниками нет проблемы, простите?
Если приходится выискивать древние высокочастотные Xeon для того, чтобы оно быстрее работало, а новые не дают прироста скорости от слова совсем.
Серверные бинарники компилируются и оптимизируются под какую версию CPU сейчас?
У нас нет разделения на серверные бинарники и не серверные. Есть разделение на 32-битные и 64-битные.
Высокая частота и новые инструкции в процессорах не должны коррелировать.
64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.
Высокая частота и новые инструкции в процессорах не должны коррелировать.
64-битные бинарники собираются с generic x64 инструкциями, включающими в себя, например, sse2 и cmov. AVX не используется, да и мест в платформе таких практически нет, где бы от них был явный выигрыш.
Проблема в том, что новые ядра, в целом, более низкочастотные. Поэтому и приходится искать старые сервера. Тогда ещё не думали об энергоэффективности.
Вот именно!
И вот, что странно. На новых Xeon те же приложения IIS почему-то работают заметно быстрее, а вот 1С — нет. Даже медленнее.
Нет оптимизации или «специфика вычислений» сказывается?
И вот, что странно. На новых Xeon те же приложения IIS почему-то работают заметно быстрее, а вот 1С — нет. Даже медленнее.
Нет оптимизации или «специфика вычислений» сказывается?
я не вижу проблемы сделать при старте платформы определение списка поддерживаемых инструкций и выбирать нужную ветку программы. Так делает любой профессиональный пакет типа Photoshop/autocad. Либо действительно тащить разные бинари и запускать нужный.
У нас был свой класс для строк, т.к. у нас в силу специфики нашего софта строковые операции используются очень широко и для нас это критично
и при этом нет нормальной возможности использовать регулярки…
Проблемы в проекте начинаются после слов программиста «О! Я знаю, как сделать это на регулярных выражениях!» (ц)
Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
Чего будет больше — вопрос очень непростой.
Ну а если серьезно — мы периодически возвращаемся к этому вопросу, но окончательного решения пока так и не приняли. Регулярные выражения — это «веревка достаточной длины чтобы выстрелить себе в ногу». Введение ее в платформу, развитие и поддержка — очень серьезная задача, влекущая за собой, помимо вложения в нее ресурсов, как плюсы, так и минусы.
Чего будет больше — вопрос очень непростой.
Я прекрасно осознаю, что некоторым программистам нельзя давать в руки спички, а не то что допускать к клавиатуре. Но грести всех под одну гребенку и лишать мощного и гибкого инструмента — это тоже перебор. Поддержка регулярных выражений имеется в каждом уважающем себя языке и мир из-за этого еще не рухнул (вне зависимости от уровня подготовки пишущих на них программистов).
А ресурсы… Я не C++ программист, но думаю задействовать стандартную библиотеку особого труда не составит.
А ресурсы… Я не C++ программист, но думаю задействовать стандартную библиотеку особого труда не составит.
задействовать стандартную библиотеку особого труда не составит.
А какую считать стандартной?
Далее, после выбора стандарта, надо документировать, обучать, поддерживать работу на разных ОС и т.д. и т.п.
Т.е. все это — весьма серьезная активность. Плюсы реализации которой, как я уже говорил, неочевидны. А не просто задействовать стандартную библиотеку.
А вот Вы не пробовали потом свои наработки оптимизайций по строкам отправить обратно для включения в boost, stl и иже с ними? Чтоб не только в будущем можно было меньше своих «костылей» лелеять внутри проекта, но и чтоб другие тоже могли воспользоваться?
Нам кажется, в этом нет особого смысла.
Для решения generic задач стандартная строка вполне подходит.
Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
Для решения generic задач стандартная строка вполне подходит.
Для решения задач частных, по моему опыту, каждый большой проект пишет строку для себя, под свои потребности и специфику, либо с нуля, либо беря за основу ту же Facebook-строку из folly например.
Т.е. польза для комьюнити от вливания нашей строки в стандарт будет, мягко говоря, спорной — наша строка хороша для наших задач, и не факт, что оптимально подойдет для других проектов.
Классов строк в open-source библиотеках немало (и в стандарт они не вошли!), и добавление нашей реализации ничего нового не привнесет.
Проблема в том, что далеко не всем нужны оптимизации SSO и Copy-On-Write. Иногда от них больше вреда, чем пользы. Да и семантика типа сильно меняется.
Уважаемый PeterG, Есть два вопроса.
1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
Прокомментируйте пожалуйста, если это не секрет.
1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
Прокомментируйте пожалуйста, если это не секрет.
1. В связи с переходом на стандарт C++17 в платформе 14 планируется ли нативная поддержка регулярных выражений?
Пока не планируется.
2. Планируется ли развитие Механизма анализа данных в сторону ML (machine learning)?
Прокомментируйте пожалуйста, если это не секрет.
Секрет :)
В смысле секрет? Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.
Объявлялось же недавно что планируется добавить возможности работы с машинным обучением. Вроде уже где то даже обкатывается.
Хм, а ссылку можно?
Кажется это было в докладе на ERP форуме
но запись трансляции целиком я почему то не смог найти, хотя смотрел интересующие меня вещи в ней, а по ссылке почему то записи именно этого доклада нет.
«Фирма „1С“. Состояние дел, стратегия и развитие корпоративного направления» Нуралиев Борис, директор, «1С»
но запись трансляции целиком я почему то не смог найти, хотя смотрел интересующие меня вещи в ней, а по ссылке почему то записи именно этого доклада нет.
Тесты после перехода показали проседание производительности (местами до 20-30%) и увеличение потребляемой памяти (до 10-15%) по сравнению со старой версией кода. Это было, в частности, связано с неоптимальной работой стандартных строк. Поэтому строку нам опять пришлось использовать свою, слегка доработанную.
Из написанного не до конца понятно производительность вернулась на прежний уровень или нет после изменений?
Не совсем касается статьи, но некоторые пожелания по развитию платформы:
1) Сделайте в конфигураторе, возможность группировать те же общие модули (хотя бы их) либо по подсистемам (про отбор по подсистемам я в курсе), либо (что лучше) вообще сделать возможность создания произвольных групп. Например создать группу «Работа с подключаемым оборудованием» или «Мои модули», а то в современных конфигурациях написанных на базе БСП и БПО, такое большое количество модулей, что становится тяжело с ними работать. При этом можно (и наверное даже нужно), чтобы эта иерархия была прозрачная для кода (тогда ничего не придется существенно изменять).
2) Для динамических списков, не хватает возможности выборки временной таблицы, бывает что есть достаточно большой объём тяжелой «статичной» информации, которую и дорого считывать постоянно, да и нет особой необходимости. Я понимаю, что это вступает в конфликт с «Динамическим считыванием», но можно же как-то разделить части запроса, какие считываются один раз, а какие данные обновляются динамически?
3) При работе с внешними источниками данных, не хватает возможности создания произвольных запросов к базе на её диалекте. Бывают ситуации, когда оптимально написать прямой запрос к базе, имея все возможности базы данных, а не только те, которые предоставляет 1С. Да, есть функции, но опять же, их нельзя создать средствами ВИД.
4) В некоторых ситуациях, в целях оптимизации дорогого вызова сервера (особенно на медленных сетях), очень не хватает событий вроде «ПередВызовомСервераНаКлиенте», «ПриВызовеСервераСКлиента», «ПередЗавершениемВызоваСервераСКлиента», «ПриЗавершенииВызоваСервераНаКлиенте». Ибо есть необходимость, каких-то периодических обращений к серверу, для получения «команд», информации и пр., при этом нет «срочности» получения информации, было бы удобно, перед вызовом сервера (как из кода, так и внутренние потребности 1С, например обновление динамического списка и пр.), в событии «ПередВызовомСервераНаКлиенте» сформировать некую произвольную структуру необходимой информации, в событии «ПриВызовеСервераСКлиента» получать её с клиента и обрабатывать ну и в событии «ПриЗавершенииВызоваСервераНаКлиенте» получать запрошенные данные с сервера. Это бы позволило минимизировать обмен с сервером и формировать некие «пакеты» на запрос к серверу. А так несколько обработчиков которым периодически нужно вызывать сервер, в разных местах + потребность платформы в вызовах сервера = Излишние обращения к серверу, которые на медленных сетях порой очень дорогие! (интернет же не везде хороший)
5) Ну и упоминавшаяся уже в комментариях, необходимость в регулярных выражениях, ибо технически, платформа умеет с ними работать (проверка типа в XDTO), но прямого доступа из кода нет. Лично для меня, это уже вторично, в некоторых местах, использую хак проверки через XDTO, хотя этот способ как мне кажется, достаточно дорог в отличии от нативной поддержки.
6) Возможность расчета контрольной суммы (Хеширование) на клиенте. Как-то не логично передавать 5 гиговый файл на сервер, только для того чтобы узнать его контрольную сумму, в данный момент приходится использовать консольные программы для этого.
7) Сделайте возможность deflate упаковки строк, сама платформа активно использует этот алгоритм в тех или иных местах, однако, разработчику данный механизм не доступен (если не рассматривать хаки через ZIP файл)
Что-то было ещё, но уже забыл. В целом мне очень нравится курс, который вы взяли начиная с 8.3.9, добавляя всё больше и больше, очень вкусных возможностей, в том числе которые «казалось бы» не нужны в «бухгалтерской» программе.
Спасибо!
1) Сделайте в конфигураторе, возможность группировать те же общие модули (хотя бы их) либо по подсистемам (про отбор по подсистемам я в курсе), либо (что лучше) вообще сделать возможность создания произвольных групп. Например создать группу «Работа с подключаемым оборудованием» или «Мои модули», а то в современных конфигурациях написанных на базе БСП и БПО, такое большое количество модулей, что становится тяжело с ними работать. При этом можно (и наверное даже нужно), чтобы эта иерархия была прозрачная для кода (тогда ничего не придется существенно изменять).
2) Для динамических списков, не хватает возможности выборки временной таблицы, бывает что есть достаточно большой объём тяжелой «статичной» информации, которую и дорого считывать постоянно, да и нет особой необходимости. Я понимаю, что это вступает в конфликт с «Динамическим считыванием», но можно же как-то разделить части запроса, какие считываются один раз, а какие данные обновляются динамически?
3) При работе с внешними источниками данных, не хватает возможности создания произвольных запросов к базе на её диалекте. Бывают ситуации, когда оптимально написать прямой запрос к базе, имея все возможности базы данных, а не только те, которые предоставляет 1С. Да, есть функции, но опять же, их нельзя создать средствами ВИД.
4) В некоторых ситуациях, в целях оптимизации дорогого вызова сервера (особенно на медленных сетях), очень не хватает событий вроде «ПередВызовомСервераНаКлиенте», «ПриВызовеСервераСКлиента», «ПередЗавершениемВызоваСервераСКлиента», «ПриЗавершенииВызоваСервераНаКлиенте». Ибо есть необходимость, каких-то периодических обращений к серверу, для получения «команд», информации и пр., при этом нет «срочности» получения информации, было бы удобно, перед вызовом сервера (как из кода, так и внутренние потребности 1С, например обновление динамического списка и пр.), в событии «ПередВызовомСервераНаКлиенте» сформировать некую произвольную структуру необходимой информации, в событии «ПриВызовеСервераСКлиента» получать её с клиента и обрабатывать ну и в событии «ПриЗавершенииВызоваСервераНаКлиенте» получать запрошенные данные с сервера. Это бы позволило минимизировать обмен с сервером и формировать некие «пакеты» на запрос к серверу. А так несколько обработчиков которым периодически нужно вызывать сервер, в разных местах + потребность платформы в вызовах сервера = Излишние обращения к серверу, которые на медленных сетях порой очень дорогие! (интернет же не везде хороший)
5) Ну и упоминавшаяся уже в комментариях, необходимость в регулярных выражениях, ибо технически, платформа умеет с ними работать (проверка типа в XDTO), но прямого доступа из кода нет. Лично для меня, это уже вторично, в некоторых местах, использую хак проверки через XDTO, хотя этот способ как мне кажется, достаточно дорог в отличии от нативной поддержки.
6) Возможность расчета контрольной суммы (Хеширование) на клиенте. Как-то не логично передавать 5 гиговый файл на сервер, только для того чтобы узнать его контрольную сумму, в данный момент приходится использовать консольные программы для этого.
7) Сделайте возможность deflate упаковки строк, сама платформа активно использует этот алгоритм в тех или иных местах, однако, разработчику данный механизм не доступен (если не рассматривать хаки через ZIP файл)
Что-то было ещё, но уже забыл. В целом мне очень нравится курс, который вы взяли начиная с 8.3.9, добавляя всё больше и больше, очень вкусных возможностей, в том числе которые «казалось бы» не нужны в «бухгалтерской» программе.
Спасибо!
А 10 мегастрок, это сколько мегабайт исходников?
А то я в последнее время приобрёл привычку сжимать исходник, чтобы колёсико мышки меньше изнашивалось.
Раньше делал так:
А теперь делаю так:
А то я в последнее время приобрёл привычку сжимать исходник, чтобы колёсико мышки меньше изнашивалось.
Раньше делал так:
if(condition)
{
code
}
else
{
code
}А теперь делаю так:
if(condition){
code
}else{
code
}
А я думаю — почему же это после обновления платформы до самой свежей всё стало жутко тормозить?
А вишь оно как… П == Прогресс.
PS. нагрузочные тесты? Не, не слышал.
А вишь оно как… П == Прогресс.
PS. нагрузочные тесты? Не, не слышал.
А во обще странно, почему тормозит. Я недавно тестировал компиляторы VS C++ 2010 и VS C++ 2017, да к новый компилятор генерирует более оптимальный код, 5-10% можно получить быстродействия, и это простой перекомпиляцией. Ну а если вдруг проект стал тормозить значит, значит к проекту прилипла что-то тормозящие, в смысле библиотека.
Легко и непринужденно:
* берем крайнюю версию платформы (8.3.13.1513, если склероз не изменяет)
* берем крайнюю версию Бухгалтерии (3.0.65.сколькототам)
* запускаем 10 штук баз одновременно (файловых, на не самом поганом немецком хостинге, на честно купленной Windows Server 2008 R2)
* сидим и курим ЧАС, пока оно взлетит
Загрузка процессора (всех четырех ядер) — 5-10%
Никаких тюнингов и выпендриваний — всё by default.
Вот как так вот?
Я такое кунг-фу не умею.
Чтобы так убить работу — я не умею.
PS. TPC говорит, что лучше, чем на этом сервере — технически существовать не может.
Шутка, конечно, но тем не менее.
* берем крайнюю версию платформы (8.3.13.1513, если склероз не изменяет)
* берем крайнюю версию Бухгалтерии (3.0.65.сколькототам)
* запускаем 10 штук баз одновременно (файловых, на не самом поганом немецком хостинге, на честно купленной Windows Server 2008 R2)
* сидим и курим ЧАС, пока оно взлетит
Загрузка процессора (всех четырех ядер) — 5-10%
Никаких тюнингов и выпендриваний — всё by default.
Вот как так вот?
Я такое кунг-фу не умею.
Чтобы так убить работу — я не умею.
PS. TPC говорит, что лучше, чем на этом сервере — технически существовать не может.
Шутка, конечно, но тем не менее.
PeterG Добрый день,
можете пожалуйста рассказать какой % кода написан на C++, а какой на других языках (без учета веб клиента, сервера взаимодейстивия, EDT и прочих явно написанных на других языках элементов инфраструктуры 1С). Надеюсь это не какая-то тайна, можно очень примерно (90 на 10, 80 на 20 и тд). Особенно интересно сколько места в платформе занимает Java и есть ли она там вообще. Если всё же Java там есть было бы супер услышать несколько примеров какие блоки на ней реализованы. Спасибо!
можете пожалуйста рассказать какой % кода написан на C++, а какой на других языках (без учета веб клиента, сервера взаимодейстивия, EDT и прочих явно написанных на других языках элементов инфраструктуры 1С). Надеюсь это не какая-то тайна, можно очень примерно (90 на 10, 80 на 20 и тд). Особенно интересно сколько места в платформе занимает Java и есть ли она там вообще. Если всё же Java там есть было бы супер услышать несколько примеров какие блоки на ней реализованы. Спасибо!
Добрый день!
Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
Я сейчас не в офисе, с разработчиками проконсультироваться не могу. Но, насколько помню, если отбросить все вами перечисленное — С++ занимает 97%-99%. Несколько визуальных контролов (точно помню про планировщик и форматированный документ) написаны с применением JavaScript.
Java, насколько помню, применяется только в EDT и Сервере Взаимодействия. Возможно еще где-то в утилитах администрирования, но 100% не уверен.
Уж коли пошла такая вечеринка — обращусь сюда.
Я сам бОльшую часть своего рабочего времени занимаюсь оптимизацией производительности баз 1С, не смотря на то что сертификата Эксперт у меня нет, потому что руки не доходят.
Что хотелось бы и не понятно почему в 1С разработчики это упорно игнорируют, хотя те же преподаватели на курсах говорят что было бы здорово если бы это было:
1) Конструктор Индексов объектов баз данных.
Поясню — не я проектирую справочники\ документы с 20-80 реквизитами и не я автор РЛС на несколько реквизитов в одной таблице. Эту проблему можно было бы достаточно малой кровью, но сейчас 3 пути решения, которые озвучиваются на том же обучении:
N1 Ничего не делать.
N2 Реализовать через вспомогательные объекты (как правило Регистры сведений), но делать 10-15 регистров сведений к тому же справочнику номенклатуры не очень здорово + требуется большая переработка существующего функционала. Да это работает, но иногда чудовищные затраты по времени.
N3 Нарушить лицензионное соглашение и добавить индексы на уровне БД и поосле реструктуризации следить за ними, потому что платформа скидывает индексы в по дефолту. Так себе решение, мало кто может это позволить, ибо решение N2 дорого сейчас, а решение N3 дорого всегда.
А бОльший пул проблем можно часто решить просто добавлением 1-2 соответствующих индексов.
2) Нет человеческого инструмента анализа логов.
Объясню: ЦУП — долго, не качественно. На том же обучении — из 5ти попыток только одна смогла проанализировать логи. Для софта за 100 000 с намеком на энтерпрайз по моему плохо.
— Скрипты на perl — неплохое решение, из рекомендуемого gitBash — чтение идет в 1 поток и скорость неудовлетворительна. У одного заказчика установка любого софта запрещена, и я еле еле вынес логи на флешке для анализа, тот же GitBash мне не поставили.
— Самописки. Каждый ваяет как может. Я написал нормализатор на Python и загружаю в SQL.
— Кто то ипользует ELK.
Но есть ситуации когда заказчик ультимативно требует только инструменты Вендора.
Не понятно почему нельзя выпустить инструмент и продавать его за деньги, если он будет лишен недостатков ЦУП — спрос будет, я сам куплю его на свои в первый же день выхода. Тем более для держателей формата тех журнала и тех кто знает основные проблемы это задача не несподъемная.
Просто по своему опыту — 30 гб логов ТЖ нормализуются в CSV на достаточно посредственной машине с HDD диском за 5-15 минут, все зависит от загруженности диска другими задачами.
Тот же Сергей Старых aka TormozIT сделал очень неплохой и достаточно быстрый анализатор логов ТЖ на 1С в инструментах разработчика, но том из — за того что данные после разбора хранятся на форме — не получится анализировать что то большое.
Большое спасибо за внимание.
Я сам бОльшую часть своего рабочего времени занимаюсь оптимизацией производительности баз 1С, не смотря на то что сертификата Эксперт у меня нет, потому что руки не доходят.
Что хотелось бы и не понятно почему в 1С разработчики это упорно игнорируют, хотя те же преподаватели на курсах говорят что было бы здорово если бы это было:
1) Конструктор Индексов объектов баз данных.
Поясню — не я проектирую справочники\ документы с 20-80 реквизитами и не я автор РЛС на несколько реквизитов в одной таблице. Эту проблему можно было бы достаточно малой кровью, но сейчас 3 пути решения, которые озвучиваются на том же обучении:
N1 Ничего не делать.
N2 Реализовать через вспомогательные объекты (как правило Регистры сведений), но делать 10-15 регистров сведений к тому же справочнику номенклатуры не очень здорово + требуется большая переработка существующего функционала. Да это работает, но иногда чудовищные затраты по времени.
N3 Нарушить лицензионное соглашение и добавить индексы на уровне БД и поосле реструктуризации следить за ними, потому что платформа скидывает индексы в по дефолту. Так себе решение, мало кто может это позволить, ибо решение N2 дорого сейчас, а решение N3 дорого всегда.
А бОльший пул проблем можно часто решить просто добавлением 1-2 соответствующих индексов.
2) Нет человеческого инструмента анализа логов.
Объясню: ЦУП — долго, не качественно. На том же обучении — из 5ти попыток только одна смогла проанализировать логи. Для софта за 100 000 с намеком на энтерпрайз по моему плохо.
— Скрипты на perl — неплохое решение, из рекомендуемого gitBash — чтение идет в 1 поток и скорость неудовлетворительна. У одного заказчика установка любого софта запрещена, и я еле еле вынес логи на флешке для анализа, тот же GitBash мне не поставили.
— Самописки. Каждый ваяет как может. Я написал нормализатор на Python и загружаю в SQL.
— Кто то ипользует ELK.
Но есть ситуации когда заказчик ультимативно требует только инструменты Вендора.
Не понятно почему нельзя выпустить инструмент и продавать его за деньги, если он будет лишен недостатков ЦУП — спрос будет, я сам куплю его на свои в первый же день выхода. Тем более для держателей формата тех журнала и тех кто знает основные проблемы это задача не несподъемная.
Просто по своему опыту — 30 гб логов ТЖ нормализуются в CSV на достаточно посредственной машине с HDD диском за 5-15 минут, все зависит от загруженности диска другими задачами.
Тот же Сергей Старых aka TormozIT сделал очень неплохой и достаточно быстрый анализатор логов ТЖ на 1С в инструментах разработчика, но том из — за того что данные после разбора хранятся на форме — не получится анализировать что то большое.
Большое спасибо за внимание.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы перевели 10 миллионов строк кода C++ на стандарт C++14 (а потом и на C++17)