Я готов зарубиться на 100к рублей с выбором компетентной стороны что почти все что вы тут написали вырвано из контекста и натянуто на глобус, чтобы доказать изначально неверные утверждения. Тратить время на это даже не буду.
Если вы добавите таймаут с механизмом ожидания, то и результаты бенчмарков будут другие.
Вот тут хоть что то, что можно измерить - где ваши тесты? Я свои привел. А их не будет, по любой причине. Ведь это утверждение крайне некомпетентного кодера.
Или возьмем этот код.
Я понимаю, многопоточка это сложно, но раз уж скинули код то отвечу. У вас очень важная часть пропущена - ваш фреймфорк поддерживает ли асинхронность вообще? Если да то как? Если через Task то использовать Enqueue, если через колбек то в методе queue.DispatchAsync можно вернуться в изначальный контекст (SynchronizationContext) и вызвать там колбек с результатом, и даже пример кода в статье есть как это сделать в секции Вот тот же код для легковесной SerialQueue (не на основе Task).
Если же фреймворк не поддерживает асинхронность то это кусок г**** а не фрейморк, а вы соответствующий ему инженер. А DispatchSync в идеале вообще не нужен, и это даже написано в его описании.
и я что-то не уверен, что механизмы, по которым работает await, будут быстрее
В статье есть тесты замера производиельности, если не уверен докажи где в них баг, так как он точно там должен быть если так. И там четко видно в каких случаях какой механизм быстрее. Но ты слишком некомпетентен чтобы даже до этого додуматься. Удачи. Больше не отвечаю на подобные старания. Еще раз спасибо что продемонстрировал типичного минусатора.
некоторые люди пытались вам объяснить, но вы не хотели их слушать, и им просто надоело с вами спорить
Это где такое? Придумали сами?
необоснованные предположения, что описанные случаи происходили только из-за отсутствия синхронных очередей
Это тоже выдумали?
таблица с тестом производительности без описания методики тестирования
Ну да, ссылка на открытый репозиторий это не методика тестирования, нужно отдельно описание каждой строчки, чтоб статья стала еще в 2 раза длиннее. Отличный совет, обойдусь без него.
он не обрабатывает случай, когда один обработчик завис в бесконечном цикле
И зачем же для демонстрации механизма синхронизации реализовывать целиком весь интерфейс Mutex, методы, которые еще и почти никогда не используются, и отсутствуют в базовом lock, используемом в большинстве случаев? И которые при желании могут быть без проблем добавлены?
Чтобы продолжить выполнять код после критической секции в исходном потоке, для чего собственнно и нужна синхронизация
Синхронизация нужна не для этого, думать о конкретных потоках вообще плохая практика, если только не идет работа с главным потоком в приложении с UI. Но даже если нужно - в исходный поток вернуться не проблема, и я даже показал в примерах кода.
... Иначе всё приложение будет однопоточным, и смысла в разных потоках и их синхронизации вообще нет.
Это такой бред что я даже отказываюсь далее как то комментировать и вести спор. Вы абсолютно не разбираетесь в синхронизации и многопоточности, и именно про это я и говорю. Дикая некомпетентность и при этом стойкое желание давать кому либо отрицательные оценки. Отличный пример комментария, спасибо.
PS. Давно уже есть идея, нужен сервис для ведения платных споров с сильной технической независимой экспертизой - если человек не готов поставить большую сумму, доказывая то, о чем спорит, значит его мнение не стоит ничего. А если готов - я бы уже озолотился на таких как вы.
Невероятно некомпетентная статья, без хоть какого либо понимания в том, о чем автор пишет. Даже аудитория хабра смогла накидать очень много комментариев с критикой. Абсолютнейший хлам.
Рейтинг - 125.
И "это" попало в подборку "лучших статей за неделю"! Сюр какой то. Во что превратился хабр? В помойку.
11 дизлайков, половина - за низкий технический уровень, треть не согласны, при том что нет НИ ОДНОГО комментария, который объяснил бы низкий технический уровень, хоть сколько нибудь конструктивный спор кто с чем не согласен, с тестами / цифрами/ примерами.
Лично мне очевидно, что голосовали люди, крайне не компетентные в данном вопросе. Я же ответил на все комменты максимально конструктивно.
Работает хорошо только меритократия, и чем лучше "качество демоса", а точнее компетентность в конкретном вопросе - тем ближе демократия к меритократии, и качественнее оценка, и наоборот. Вы же не просите соседей голосовать как лечить боль в животе, а обращаетесь к врачу, да хочется к очень хорошему а не абы какому?
На хабре сейчас крайне низкий средний уровень компетентности, хотя он в целом низкий у населения Земли - IQ у 95% людей ниже 125, а даже этот уровень вообще ни о чем. А интеллект это базовая составляющая компетентности.
Поэтому все эти оценки, да еще и зависимость личного рейтинга и кармы от "рукожопов" - по сути отрицательный отбор, абсурд.
Добавьте возможность тем кто пишет статьи не давать возможность ставить дизы без комментария. Критикуешь - предлагай. И в идеале если коммент не содержит ничего конструктивного (просто - не согласен), то минус не засчитывать. Можно хотя бы ИИшкой проверять наличие конструктива.
Самые лучшие статьи имеют дофигища минусов, а откровенный хлам набирает одни плюсы. Все, что даёт понять такой рейтинг, это что демократия в науке не работает совсем.
На хабре катастрофа с компетентностью статей, голосуют в основном стажеры/джуны/мидлы, чем хуже статья тем лучше рейтинг - конечно же самое время вводить реакции.
Когда то давно помню накладывал полупрозрачные картинки поверх симуляторов - для мака какой то плагин был даже чтобы для любого окна можно было поменять прозрачность.
Но последнее время если прям точно надо (что бывает редко), то делаю скриншот с симулятора / эмулятора и в Preview замеряю отступ с помощью выделения. По возможности стараюсь делегировать это на отдел тестирования.
Очень часто бывает, что чтобы сделать pixel perfect интерфейс, отступы в коде должны немного отличаться от макетов из за мелких отличий того или иного встроенного компонента, шрифта или экспортированной картинки.
Также, не помню чтоб была проблема нестандартных отступов там где не нужно - действительно ли она существует чтоб ее решать?
Если же речь идет о 100% одинаковом отступе для компонентов на одном экране, например схожие но разные ячейки, то конечно иногда имеет смысл вынести его в константу, а то и экспортировать общие стили, сам так много раз делал. Добавлю это в статью.
Я в статье как раз пишу в пункте 2.2, что в вашем случае стили создаются каждым компонентом, что плохо влияет на производительность. В моем случае они переиспользуются всеми компонентами, и нет дополнительного useMemo. Также в вашем случае я вижу придется еще и creator в useCallback заворачивать, либо выносить из компонента.
Swift изначально был ужасно спроектированным языком, знаю его с первой версии. Лучший пример слова "оверинжиниринг". Взять только реализацию массивов и словарей, от чего многие продолжали использовать нетипизированные NS* версии. А компилятор, который показывал все что угодно но не причину ошибки?
Когда подключилось сообщество, то очень многие проблемы стали потихоньку решаться. Но в любом случае он остается языком "одной платформы", и довольно неудачным языком. А Apple доказала что не может разработать ни хороший язык, ни, после выхода SwiftUI, хороший фреймворк. Про ужасную среду разработки даже вспоминать не хочу.
По итогу ушел в разработку на TS на React Native и не планирую возвращаться ни при каких обстоятельствах.
Отдельные недостатки это обучение ненужным языкам и отсутствие крайне важных технологии в виде git, веб разработки, баз данных и тп? Алкаши-препода что не приходят на пары и не интересуются курсовыми / дипломными, другие сами не понимают в своем предмете, третьи не имели ни дня практики и пересказывают учебник?
Да и как студентам обучаться самим какой то технологии, если они не в курсе ее существования?
Я не знал и что такое система управления версиями в принципе. Из языков - Delphi и Pascal, на тот момент уже никому не нужные. И совсем немного Matlab, VBA и C++.
Я готов зарубиться на 100к рублей с выбором компетентной стороны что почти все что вы тут написали вырвано из контекста и натянуто на глобус, чтобы доказать изначально неверные утверждения. Тратить время на это даже не буду.
Вот тут хоть что то, что можно измерить - где ваши тесты? Я свои привел. А их не будет, по любой причине. Ведь это утверждение крайне некомпетентного кодера.
Я понимаю, многопоточка это сложно, но раз уж скинули код то отвечу. У вас очень важная часть пропущена - ваш фреймфорк поддерживает ли асинхронность вообще? Если да то как? Если через Task то использовать Enqueue, если через колбек то в методе queue.DispatchAsync можно вернуться в изначальный контекст (SynchronizationContext) и вызвать там колбек с результатом, и даже пример кода в статье есть как это сделать в секции Вот тот же код для легковесной SerialQueue (не на основе Task).
Если же фреймворк не поддерживает асинхронность то это кусок г**** а не фрейморк, а вы соответствующий ему инженер. А DispatchSync в идеале вообще не нужен, и это даже написано в его описании.
В статье есть тесты замера производиельности, если не уверен докажи где в них баг, так как он точно там должен быть если так. И там четко видно в каких случаях какой механизм быстрее. Но ты слишком некомпетентен чтобы даже до этого додуматься. Удачи. Больше не отвечаю на подобные старания. Еще раз спасибо что продемонстрировал типичного минусатора.
MobX это библиотека для тех, кто в архитектуре не разбирается. Ее вообще не стоит где либо использовать, пора уже похоронить.
Это где такое? Придумали сами?
Это тоже выдумали?
Ну да, ссылка на открытый репозиторий это не методика тестирования, нужно отдельно описание каждой строчки, чтоб статья стала еще в 2 раза длиннее. Отличный совет, обойдусь без него.
И зачем же для демонстрации механизма синхронизации реализовывать целиком весь интерфейс Mutex, методы, которые еще и почти никогда не используются, и отсутствуют в базовом lock, используемом в большинстве случаев? И которые при желании могут быть без проблем добавлены?
Синхронизация нужна не для этого, думать о конкретных потоках вообще плохая практика, если только не идет работа с главным потоком в приложении с UI. Но даже если нужно - в исходный поток вернуться не проблема, и я даже показал в примерах кода.
Это такой бред что я даже отказываюсь далее как то комментировать и вести спор. Вы абсолютно не разбираетесь в синхронизации и многопоточности, и именно про это я и говорю. Дикая некомпетентность и при этом стойкое желание давать кому либо отрицательные оценки. Отличный пример комментария, спасибо.
PS. Давно уже есть идея, нужен сервис для ведения платных споров с сильной технической независимой экспертизой - если человек не готов поставить большую сумму, доказывая то, о чем спорит, значит его мнение не стоит ничего. А если готов - я бы уже озолотился на таких как вы.
Вы в курсе что видите только общий рейтинг, который все плюсы минус все минусы?
Где я писал что любая заминусованная статья автоматически хорошая, а любая заплюсованная автоматически плохая?
А вот обратный пример https://habr.com/ru/companies/selectel/articles/852468/
Невероятно некомпетентная статья, без хоть какого либо понимания в том, о чем автор пишет. Даже аудитория хабра смогла накидать очень много комментариев с критикой. Абсолютнейший хлам.
Рейтинг - 125.
И "это" попало в подборку "лучших статей за неделю"! Сюр какой то. Во что превратился хабр? В помойку.
https://habr.com/ru/articles/803273/
11 дизлайков, половина - за низкий технический уровень, треть не согласны, при том что нет НИ ОДНОГО комментария, который объяснил бы низкий технический уровень, хоть сколько нибудь конструктивный спор кто с чем не согласен, с тестами / цифрами/ примерами.
Лично мне очевидно, что голосовали люди, крайне не компетентные в данном вопросе. Я же ответил на все комменты максимально конструктивно.
Работает хорошо только меритократия, и чем лучше "качество демоса", а точнее компетентность в конкретном вопросе - тем ближе демократия к меритократии, и качественнее оценка, и наоборот. Вы же не просите соседей голосовать как лечить боль в животе, а обращаетесь к врачу, да хочется к очень хорошему а не абы какому?
На хабре сейчас крайне низкий средний уровень компетентности, хотя он в целом низкий у населения Земли - IQ у 95% людей ниже 125, а даже этот уровень вообще ни о чем. А интеллект это базовая составляющая компетентности.
Поэтому все эти оценки, да еще и зависимость личного рейтинга и кармы от "рукожопов" - по сути отрицательный отбор, абсурд.
Оценка от чатжпт:
За оригинальность и выражение точки зрения: 30 баллов.
За недостаток конструктивности и конкретики: -70 баллов.
Итог: 30/100.
Добавьте возможность тем кто пишет статьи не давать возможность ставить дизы без комментария. Критикуешь - предлагай. И в идеале если коммент не содержит ничего конструктивного (просто - не согласен), то минус не засчитывать. Можно хотя бы ИИшкой проверять наличие конструктива.
Самые лучшие статьи имеют дофигища минусов, а откровенный хлам набирает одни плюсы. Все, что даёт понять такой рейтинг, это что демократия в науке не работает совсем.
На хабре катастрофа с компетентностью статей, голосуют в основном стажеры/джуны/мидлы, чем хуже статья тем лучше рейтинг - конечно же самое время вводить реакции.
Про разные файлы для стилей и читаемость тоже писал в пункте 2.1.
Когда то давно помню накладывал полупрозрачные картинки поверх симуляторов - для мака какой то плагин был даже чтобы для любого окна можно было поменять прозрачность.
Но последнее время если прям точно надо (что бывает редко), то делаю скриншот с симулятора / эмулятора и в Preview замеряю отступ с помощью выделения. По возможности стараюсь делегировать это на отдел тестирования.
Очень часто бывает, что чтобы сделать pixel perfect интерфейс, отступы в коде должны немного отличаться от макетов из за мелких отличий того или иного встроенного компонента, шрифта или экспортированной картинки.
Также, не помню чтоб была проблема нестандартных отступов там где не нужно - действительно ли она существует чтоб ее решать?
Если же речь идет о 100% одинаковом отступе для компонентов на одном экране, например схожие но разные ячейки, то конечно иногда имеет смысл вынести его в константу, а то и экспортировать общие стили, сам так много раз делал. Добавлю это в статью.
Но спасибо за мнение.
В пункте 2.4 указал, что правило eslint для определения неиспользуемых стилей к сожалению пока не работает с такой мемоизацией.
Я в статье как раз пишу в пункте 2.2, что в вашем случае стили создаются каждым компонентом, что плохо влияет на производительность. В моем случае они переиспользуются всеми компонентами, и нет дополнительного
useMemo. Также в вашем случае я вижу придется еще иcreatorвuseCallbackзаворачивать, либо выносить из компонента.Swift изначально был ужасно спроектированным языком, знаю его с первой версии. Лучший пример слова "оверинжиниринг". Взять только реализацию массивов и словарей, от чего многие продолжали использовать нетипизированные NS* версии. А компилятор, который показывал все что угодно но не причину ошибки?
Когда подключилось сообщество, то очень многие проблемы стали потихоньку решаться. Но в любом случае он остается языком "одной платформы", и довольно неудачным языком. А Apple доказала что не может разработать ни хороший язык, ни, после выхода SwiftUI, хороший фреймворк. Про ужасную среду разработки даже вспоминать не хочу.
По итогу ушел в разработку на TS на React Native и не планирую возвращаться ни при каких обстоятельствах.
Отдельные недостатки это обучение ненужным языкам и отсутствие крайне важных технологии в виде git, веб разработки, баз данных и тп? Алкаши-препода что не приходят на пары и не интересуются курсовыми / дипломными, другие сами не понимают в своем предмете, третьи не имели ни дня практики и пересказывают учебник?
Да и как студентам обучаться самим какой то технологии, если они не в курсе ее существования?
Я не знал и что такое система управления версиями в принципе. Из языков - Delphi и Pascal, на тот момент уже никому не нужные. И совсем немного Matlab, VBA и C++.
Я после 5 лет российского вуза программерского факультета (2006-2011) понятия не имел что такое git, а тут хоть что то ответил, молодец 😂.