Живее всех живых: Telegram набирает мощь несмотря на неполадки сервиса
Не далее как вчера произошел масштабный сбой в работе Telegram’а – первые жалобы на неполадки в работе мессенджера начали поступать около 11:00 по московскому времени.
Пользователи столкнулись с тем, что невозможно было обновить список диалогов и отправить сообщения.
Из-за поднявшейся среди пользователей Telegram паники и домыслов о преждевременной блокировке мессенджера Роскомнадзором, ведомство было вынуждено оперативно сделать официальное заявление о своей непричастности:
Позже причину трехчасового сбоя объяснил Павел Дуров – неполадки были вызваны техническими работами, которые осуществляла компания, обслуживающая дата-центр. В ходе проведения плановых работ произошло обесточивание кластера серверов Telegram, которое и привело к отключению сервиса.
«Все сервисы, которые растут, обречены на связанные с этим ростом проблемы. К сожалению, Telegram не является исключением, хотя мы и стараемся быть таковым», – отметил Павел Дуров в своем Telegram-канале.
Также Дуров извинился перед пользователями и пообещал в дальнейшем избегать подобных ситуаций:
«Чтобы убедиться, что подобные сбои не повторятся, мы улучшили связь между нашими инженерами и электриками центра обработки данных и, что важнее – начали модернизировать электрооборудование, чтобы увеличить запас мощности».
На вести о неполадках в работе мессенджера из-за отключения электропитания Роскомнадзор также не преминул отреагировать ехидным замечанием:
Однако стоит отметить, что несмотря на подобные казусы в работе Telegram’а, его дела идут крайне успешно. Так, в среду 28 марта Дуров объявил в своем канале о ежедневном приросте аудитории мессенджера: «На этой неделе в Telegram ежедневно регистрируются 700 тысяч новых пользователей. Рост аудитории за год по сравнению с прошлым годом превысил 70% на большинстве рынков».
Не заставило себя ждать и очередное подтверждение финансовой успешности проекта. Как стало известно из документов, опубликованных 29 марта на сайте Комиссии по ценным бумагам и биржам США (SEC), компании удалось привлечь еще 850 млн долларов на развитие своего мессенджера и заявленной ранее блокчейн-платформы TON. В общей сложности братья Дуровы собрали около 1,7 млрд долларов.
Как стало понятно по реакции пользователей соцсетей, временные проблемы в работе мессенджера Telegram насторожили если не всех, то многих. Оказывается, отключение привычной площадки для общения возможно в самый неподходящий момент. А если вместе с досужей перепиской остановятся важнейшие бизнес-процессы, так как будет парализовано корпоративное общение всей компании? В какой мессенджер уходить из «упавшего»? Призываем Сообщество INFOSTART.RU поучаствовать в нашем опросе.
Автор:
Яна Казьмина
Редактор ленты новостей
Чем вы пользуетесь для оперативной коммуникации в своей компании?
Telegram (25.93%, 35 голосов)
25.93%
WhatsApp (12.59%, 17 голосов)
12.59%
Viber (12.59%, 17 голосов)
12.59%
Skype (22.22%, 30 голосов)
22.22%
Slack (2.22%, 3 голосов)
2.22%
Messenger (FB) (0%, 0 голосов)
0%
ICQ (3.7%, 5 голосов)
3.7%
VK (0.74%, 1 голосов)
0.74%
Google Hangouts (0%, 0 голосов)
0%
Битрикс24 (2.96%, 4 голосов)
2.96%
Электронная почта (9.63%, 13 голосов)
9.63%
iMessage (0%, 0 голосов)
0%
Проводной телефон (5.19%, 7 голосов)
5.19%
Другой вариант (в комментарии) (2.22%, 3 голосов)
2.22%
Комментарии
Избранное
Подписка
Сортировка:
Древо
Очнитесь, неужели нельзя с гораздо большей пользой потратить "1,7 млрд долларов", нежели чем на какой-то мессенджер, который пишется на коленке любым школьником на любом доступном языке программирования. Деградация...
(2)
Так напиши свой раз всё так просто.
Очнитесь, неужели нельзя с гораздо большей пользой потратить "1,7 млрд долларов", нежели чем на какой-то мессенджер, который пишется на коленке любым школьником на любом доступном языке программирования. Деградация...
Так напиши свой раз всё так просто.
(5) Даже если кто-то и напишет мессенджер лучше чем все существующие на данный момент, даже если и бесплатно, с открытым исходным кодом, блэкджеком и девушками с низкой социальной ответственностью. Никто ими пользоваться не будет. Просто потому, что не хватит денег на рекламу, чтобы собрать нужную аудиторию. У Дурова деньги были благодаря рекламодателям из ВКонтакт. Вот как бы и все. Чем ты популярнее, тем больше шансов у тебя толкнуть какой-нибудь хлам по завышенной цене, как и действует большинство брендов. 1С такой же бренд. Им пользуются многие потому, что им пользуются многие. Лавинообразный процесс. Как продукт, что Telgram, что 1С - низкосортные поделки. Нас бы тут с вами не было бы, если не хотели бы получить кусок пирога с хайпа. E-mail как технология безбожно устарела, ровно как и FTP и куча еще всего, но ими пользуются. При этом такую крутую вещь как bittorent почему-то нативно ни в браузеры ни в ОС не внедряют. Да что там говорить, игры для PC пишутся в основном под Windows, а не Linux только потому, что аудитория больше - замкнутый круг, не можем пользоваться чем-то стоящим, т.к. кому-то это не выгодно...
(8)Ну я ежедневно пользуюсь и тем и другим, мук не испытываю. ЧЯДНТ? Мне казалось, что реклама это когда заплатили за упоминание. Иначе это обсуждение. Вы считаете, что редактору занесли денег из компании дурова, что бы он рассказал про технический сбой?
(9)
Мало программируешь?
Вот пример, сегодняшний. Понадобилось мне в 1С на стороне клиента отсортировать массив либо по возрастанию, либо по убыванию, в котором 50000 объектов типа Структура с заполненными ключами. Сортировка должна быть по одному из этих ключей. Обычно все как делают - берут ТаблицуЗначений (сервер only) или СписокЗначений (доступен и на клиенте и на сервере). Чтобы отсортировать через ТЗ - надо перекачать массив на сервер, там создать объект, добавить поля, в цикле раскидать все ключи по полям, затем отсортировать и выгрузить обратно в массив. СписокЗначений, как класс полный отстой, т.к. позволяет сортировать только по значению, но никак не по одному из полей этого значения. Отметаем сразу.
Выбор пал на собственную реализацию алгоритма QuickSort (qsort), т.к. по известным причинам многого полезного в 1С отродясь нет и, похоже, не предвидеться. Реализовал пробный вариант. Первое во что я уперся это в рекурсию. Из-за нее отъелось непомерно много оперативной памяти и в какой-то момент клиент вышел за пределы и начал выполнять функции определенные в модуле формы, которые вообще ни откуда не вызываются, а были оставлены для отладки. Ладно думаю, буду реализовывать итеративный вариант сортировки. Переписал алгоритм с нуля. Запустил на тестовом массиве обычных случайных чисел, по диспетчеру задач видно, что потребление памяти нулевое, т.е. не растет. Процессор загружен на 16%. Через 1,5 минуты я увидел результат. Погуглил в интернете сколько времени занимает сортировка массива чисел на С++ быстрой сортировкой и выпал в осадок. Доли секунд. Пришло осознание, что надо оптимизировать код дальше. Первое что было сделано - любые вызовы собственных функций типа partition() и swap() были захардкожены в цикл. Скорость сортировки после этого возросла в 2 раза. Затем стало ясно что оптимизировать дальше особое нечего, т.к. невозможно оптимизироваться операции сложения или вычитания. Порывшись еще в интернете я решил попробовать свернуть цикл в одну строку. Скорость возросла с 40 секунд, до 10 секунд. Затем я решил свернуть в одну строку функцию целиком. И скорость сортировки стала 3,5 секунды.
Напомню это был тестовый массив. Дело дошло до реального массива, где нужен собственный компаратор, где уже не отделаешься инструкцией сравнения "arr[i]<=pivot". Кроме того нужен был контроль над сортировкой, по убыванию или по возрастанию. Когда я внес коррективы в алгоритм - скорость сортировки стала 70 секунд. Нормально, да? За универсальность я не был готов платить скоростью, поэтому реализовал 3 практически идентичные функции сортировки: а) классическую б) для сравнения по ключам объекта по убыванию в) для сравнения по ключам объекта по возрастанию. Затем я решил попробовать перегнать данные на сервер и отсортировать через ТЗ. И я получил все те же 3,5 секунды чистой сортировки без учета времени на переброс туда сюда. Но при этом на rphoste при заполнении ТЗ память отъедалась на пару гигабайт. А на клиенте при той же скорости она была стабильно той же самой что и до сортировки. Итак, убито несколько часов. Работодатель за это заплатит, все здорово, задача решена. И вы хотите сказать, что это нормально? Решать задачу, которая решается на С++ за 5 минут с такими танцами и бубном?
ЧЯДНТ?
Мало программируешь?
Вот пример, сегодняшний. Понадобилось мне в 1С на стороне клиента отсортировать массив либо по возрастанию, либо по убыванию, в котором 50000 объектов типа Структура с заполненными ключами. Сортировка должна быть по одному из этих ключей. Обычно все как делают - берут ТаблицуЗначений (сервер only) или СписокЗначений (доступен и на клиенте и на сервере). Чтобы отсортировать через ТЗ - надо перекачать массив на сервер, там создать объект, добавить поля, в цикле раскидать все ключи по полям, затем отсортировать и выгрузить обратно в массив. СписокЗначений, как класс полный отстой, т.к. позволяет сортировать только по значению, но никак не по одному из полей этого значения. Отметаем сразу.
Выбор пал на собственную реализацию алгоритма QuickSort (qsort), т.к. по известным причинам многого полезного в 1С отродясь нет и, похоже, не предвидеться. Реализовал пробный вариант. Первое во что я уперся это в рекурсию. Из-за нее отъелось непомерно много оперативной памяти и в какой-то момент клиент вышел за пределы и начал выполнять функции определенные в модуле формы, которые вообще ни откуда не вызываются, а были оставлены для отладки. Ладно думаю, буду реализовывать итеративный вариант сортировки. Переписал алгоритм с нуля. Запустил на тестовом массиве обычных случайных чисел, по диспетчеру задач видно, что потребление памяти нулевое, т.е. не растет. Процессор загружен на 16%. Через 1,5 минуты я увидел результат. Погуглил в интернете сколько времени занимает сортировка массива чисел на С++ быстрой сортировкой и выпал в осадок. Доли секунд. Пришло осознание, что надо оптимизировать код дальше. Первое что было сделано - любые вызовы собственных функций типа partition() и swap() были захардкожены в цикл. Скорость сортировки после этого возросла в 2 раза. Затем стало ясно что оптимизировать дальше особое нечего, т.к. невозможно оптимизироваться операции сложения или вычитания. Порывшись еще в интернете я решил попробовать свернуть цикл в одну строку. Скорость возросла с 40 секунд, до 10 секунд. Затем я решил свернуть в одну строку функцию целиком. И скорость сортировки стала 3,5 секунды.
Напомню это был тестовый массив. Дело дошло до реального массива, где нужен собственный компаратор, где уже не отделаешься инструкцией сравнения "arr[i]<=pivot". Кроме того нужен был контроль над сортировкой, по убыванию или по возрастанию. Когда я внес коррективы в алгоритм - скорость сортировки стала 70 секунд. Нормально, да? За универсальность я не был готов платить скоростью, поэтому реализовал 3 практически идентичные функции сортировки: а) классическую б) для сравнения по ключам объекта по убыванию в) для сравнения по ключам объекта по возрастанию. Затем я решил попробовать перегнать данные на сервер и отсортировать через ТЗ. И я получил все те же 3,5 секунды чистой сортировки без учета времени на переброс туда сюда. Но при этом на rphoste при заполнении ТЗ память отъедалась на пару гигабайт. А на клиенте при той же скорости она была стабильно той же самой что и до сортировки. Итак, убито несколько часов. Работодатель за это заплатит, все здорово, задача решена. И вы хотите сказать, что это нормально? Решать задачу, которая решается на С++ за 5 минут с такими танцами и бубном?
(12)Я так понимаю, это клиент на вводил 50к строк? Откуда они взялись такие большие несортированные данные на клиенте? Которые не надо будет записывать в БД или каким либо образом тащить на сервер, но срочно надо отсортировать на клиенте? Легко можно таких примеров нарисовать но в данном случае ошибка на этапе проектирования. Деталей я не могу знать, но очень похоже на то, что вы героически решаете проблему которую сами себе создали. И да простыни с деталями реализации к чему?
Вот особенно это смешно:
Я начал писать на эту тему, но бросил. Как то даже не знаю, что сказать вам на возражения плана "я не могу отсортировать 50к структур по ключам на клиенте 1С отстой". Если вы не видите, что не так в этой фразе,то как бы тут не об чем говорить :)
Вот особенно это смешно:
Решать задачу, которая решается на С++ за 5 минут с такими танцами и бубном
Я начал писать на эту тему, но бросил. Как то даже не знаю, что сказать вам на возражения плана "я не могу отсортировать 50к структур по ключам на клиенте 1С отстой". Если вы не видите, что не так в этой фразе,то как бы тут не об чем говорить :)
(13) Вот именно так все 1Сники и отвечают - пытаются отговорить делать что-то, мол если этого нет, то оно вам и не нужно. Зато комментариев того, что интерпретатор 1С вообще никак не оптимизирован, о чем я рассказал, от вас не поступило. Где это видано, чтобы количество переводов строк так сильно влияло на скорость кода? И еще раз, задача решается на стороне сервера, но решается она "на соплях", т.к. ОЗУ под ТЗ не безгранична, в то время, как моя реализация сортировки работает везде и не требует дополнительной памяти. Про 16% загрузки процессора вы тоже умолчали, хотя это прямо говорит о том, что не умеет 1С задействовать все ядра процессора, предпочитая его частоту, оставшись где-то в начале 2000-х по своему развитию. Одно появление 64 битного клиента в прошлом году ясно это подтверждает.
(14)
Вам говорят вы ошиблись при проектировании. Необходимость оперировать большим объемом данных на клиенте указывает на ошибка проектирования приложения. На клиенте должны быть только те данные на которые клиент смотрит. В идеале конечно. Бывают исключения разумеется. Но и адекватные решения этих проблем тоже как правило находятся. Вам не говорят, что вам, что то нужно или не нужно. Может вы больше писать любите, а не читать?
У меня нет комментариев по этому поводу, просто об этом я впервые слышу от вас. Про то, что 1С задействует одно ядро процессора, да есть такое. Но это тоже решаемый вопрос. Просто код надо писать по другому. Не вижу здесь сюрпризов. Один поток - одно ядро.
Вот именно так все 1Сники и отвечают
Вам говорят вы ошиблись при проектировании. Необходимость оперировать большим объемом данных на клиенте указывает на ошибка проектирования приложения. На клиенте должны быть только те данные на которые клиент смотрит. В идеале конечно. Бывают исключения разумеется. Но и адекватные решения этих проблем тоже как правило находятся. Вам не говорят, что вам, что то нужно или не нужно. Может вы больше писать любите, а не читать?
Где это видано, чтобы количество переводов строк так сильно влияло на скорость кода?
У меня нет комментариев по этому поводу, просто об этом я впервые слышу от вас. Про то, что 1С задействует одно ядро процессора, да есть такое. Но это тоже решаемый вопрос. Просто код надо писать по другому. Не вижу здесь сюрпризов. Один поток - одно ядро.
(15)
50000 элементов это уже Big Data для 1С? С сортировкой такого малого количества элементов легко справится даже JavaScript в браузере. Только что замерил, 10 лямов элементов сортируются в Chrome имплементацией quicksort на JavaScript - 2 секунды. На С++ это будут доли секунды.
(15)
Скажите это разработчикам 1С, которые в платформу не включили стандартные функции библиотеки С++, которыми сами с удовольствием пользуются, но своих клиентов-разработчиков ставят раком.
Необходимость оперировать большим объемом данных на клиенте указывает на ошибка проектирования приложения.
50000 элементов это уже Big Data для 1С? С сортировкой такого малого количества элементов легко справится даже JavaScript в браузере. Только что замерил, 10 лямов элементов сортируются в Chrome имплементацией quicksort на JavaScript - 2 секунды. На С++ это будут доли секунды.
(15)
Просто код надо писать по другому
Скажите это разработчикам 1С, которые в платформу не включили стандартные функции библиотеки С++, которыми сами с удовольствием пользуются, но своих клиентов-разработчиков ставят раком.
(16)
Очень сложно вам возражать, вы мне постоянно приписываете то, чего я не говорил. Я говорю, что все операции по обработке данных должны происходить на сервере кроме элементарных. Клиент должен оперировать теми данными которые он видит на экране. Вы решили делать по своему. Решайте проблему которую себе создали, в данном конкретном случае 1С не при чем. У 1С есть проблемы как у любого другого софта, но в данном случае она не при чем. Вся наша переписка умещается в двух предложениях: "1С плохая, даже сортировка массива структур на клиенте не возможна.". Каждый раз когда на истерики я задаю вопрос по существу, мне рассказывают, как сложно забивать микроскопом гвозди, ну еще иногда упоминают про то, что там пишут на русском языке. Реальные проблемы упоминают только те, кто зарабатывает этим на жизнь. Как я понял это не вы.
Просто лозунги и общие фразы, ничего нового. Может вместо простыни в (9) надо было перечислить эти баги, рассказать как у тебя тормознутость а у пацанов вон прайсы в миллионы строк грузятся нон строп в базу в несколько потоков. И функционал настолько скудный, что за 10к рядом и поставить то особо не чего, с функционалом хотя бы в половину от простенькой УНФ не говоря уже про УТ11 или БП. Но это конфигурации да. Но они реализуют функционал платформы и вроде даже получается.
Я не первый год пишу на 1С и видел 77, еще я немного писал на питоне и пхп, написал к примеру на питоне Так вот, у 1с есть обработка раскраски кода. То есть скармливаешь ей 1С код а она тебе отдает этот код раскрашенный в html что бы можно было вставить его куда-нибудь в блог. Я взял и переписал буква в букву алгоритм из обработки 1С в питон. 1С огромные куски раскрашивает за доли секунд. Питон над среднего размера кусками кода повисал секунд на 10. Тут надо сказать, что в питон все объекты и строки в том числе. И никто не ожидает, что ты будешь работать с текстом перебирая буквы в цикле. Для этого есть регулярные выражения. Но тут можно писать гневный пост, как же так? Что это за биг дата для питона, почему это он давится тем, что 1С глотает не жуя.
Да нарисуйте обертку. для нужных вам функций и включите как компоненту, раз уж вам не достает этих функций. Как здесь
50000 элементов это уже Big Data для 1С?
Очень сложно вам возражать, вы мне постоянно приписываете то, чего я не говорил. Я говорю, что все операции по обработке данных должны происходить на сервере кроме элементарных. Клиент должен оперировать теми данными которые он видит на экране. Вы решили делать по своему. Решайте проблему которую себе создали, в данном конкретном случае 1С не при чем. У 1С есть проблемы как у любого другого софта, но в данном случае она не при чем. Вся наша переписка умещается в двух предложениях: "1С плохая, даже сортировка массива структур на клиенте не возможна.". Каждый раз когда на истерики я задаю вопрос по существу, мне рассказывают, как сложно забивать микроскопом гвозди, ну еще иногда упоминают про то, что там пишут на русском языке. Реальные проблемы упоминают только те, кто зарабатывает этим на жизнь. Как я понял это не вы.
1С в принципе не лучшая платформа для очень многих вещей. Дело даже не в сортировке. Я писал на многих языках программирования, такого скудного функционала, тормознутости и откровенных багов как в 1С нигде не видел. Вместо того, чтобы взять лучшие практики разработки и доработать платформу, фирма 1С штампует конфигурации. Самое печальное то, что в итоге до них это доходит, о чем видно в "Зазеркалье", но с огроооомным лагом.
Просто лозунги и общие фразы, ничего нового. Может вместо простыни в (9) надо было перечислить эти баги, рассказать как у тебя тормознутость а у пацанов вон прайсы в миллионы строк грузятся нон строп в базу в несколько потоков. И функционал настолько скудный, что за 10к рядом и поставить то особо не чего, с функционалом хотя бы в половину от простенькой УНФ не говоря уже про УТ11 или БП. Но это конфигурации да. Но они реализуют функционал платформы и вроде даже получается.
Я не первый год пишу на 1С и видел 77, еще я немного писал на питоне и пхп, написал к примеру на питоне Так вот, у 1с есть обработка раскраски кода. То есть скармливаешь ей 1С код а она тебе отдает этот код раскрашенный в html что бы можно было вставить его куда-нибудь в блог. Я взял и переписал буква в букву алгоритм из обработки 1С в питон. 1С огромные куски раскрашивает за доли секунд. Питон над среднего размера кусками кода повисал секунд на 10. Тут надо сказать, что в питон все объекты и строки в том числе. И никто не ожидает, что ты будешь работать с текстом перебирая буквы в цикле. Для этого есть регулярные выражения. Но тут можно писать гневный пост, как же так? Что это за биг дата для питона, почему это он давится тем, что 1С глотает не жуя.
Скажите это разработчикам 1С, которые в платформу не включили стандартные функции библиотеки С++, которыми сами с удовольствием пользуются, но своих клиентов-разработчиков ставят раком.
Да нарисуйте обертку. для нужных вам функций и включите как компоненту, раз уж вам не достает этих функций. Как здесь
(19)
А я говорю, что есть операции с которыми легко справляются мобильные телефоны на стороне клиента и гонять данные между сервером и клиентом нет смысла. Сортировка небольшого массива одна из таких операций, железо позволяет - платформа нет. Значит причина в платформе.
(19)
Про тормознутость Python'а полно информации в интернете. То, что разработчики ничего с этим не делают - плохо. Как показало время, даже движок JavaScript удалось создать достаточно быстрым. Дело в программистах.
(19)
Перечислить кому, 1С? Думаю они прекрасно о них знают.
(19)
Вы смотрели исходный код "Инструментов разработчика" Сергея Старых? То, как ему пришлось изгаляться с внешними компонентами, консольными утилитами, COM объектами, Shell скриптами - достойно уважения. К сожалению эта связка работает не всегда стабильно, начиная от ложных срабатываний антивируса, подвисанием интерфейса и заканчивая несовместимостью компонент с разрядностью клиента (32 или 64 бита). Это Франкенштейн. Вместо улучшения и развития технологической платформы, предлагаете лепить костыли, или внедряться в процесс 1С как Snegopat, чтобы получить нужный функционал? Одно существования этих двух проектов уже говорит о том, что платформа морально устарела и не отвечает современным требованиям.
Я говорю, что все операции по обработке данных должны происходить на сервере кроме элементарных
А я говорю, что есть операции с которыми легко справляются мобильные телефоны на стороне клиента и гонять данные между сервером и клиентом нет смысла. Сортировка небольшого массива одна из таких операций, железо позволяет - платформа нет. Значит причина в платформе.
(19)
Питон над среднего размера кусками кода повисал секунд на 10
Про тормознутость Python'а полно информации в интернете. То, что разработчики ничего с этим не делают - плохо. Как показало время, даже движок JavaScript удалось создать достаточно быстрым. Дело в программистах.
(19)
Может вместо простыни в (9) надо было перечислить эти баги
Перечислить кому, 1С? Думаю они прекрасно о них знают.
(19)
Да нарисуйте обертку. для нужных вам функций и включите как компоненту
Вы смотрели исходный код "Инструментов разработчика" Сергея Старых? То, как ему пришлось изгаляться с внешними компонентами, консольными утилитами, COM объектами, Shell скриптами - достойно уважения. К сожалению эта связка работает не всегда стабильно, начиная от ложных срабатываний антивируса, подвисанием интерфейса и заканчивая несовместимостью компонент с разрядностью клиента (32 или 64 бита). Это Франкенштейн. Вместо улучшения и развития технологической платформы, предлагаете лепить костыли, или внедряться в процесс 1С как Snegopat, чтобы получить нужный функционал? Одно существования этих двух проектов уже говорит о том, что платформа морально устарела и не отвечает современным требованиям.
(21)
Не знаю, вам виднее конечно, считается нормальным или нет сортировать 50к структур на мобильном устройстве клиента. Тут просто архитектура предполагает, что вы будете это делать на сервере. Можно упереться рогом в "я хочу и мне все равно". Но платформа то тут причем?
Причем питон настолько тормознутый, что на нем писали ютуб и линкед. Да, какие то движки быстрее какие-то медленнее. Это объективный факт, тем не менее выпилить питон из какого нить убунту, почти никак. Программисты так страдают, что очень много на нем пишут.
Перечислить как хоть какие-то аргументы, кроме того, что у вас плохо получилось написать свою реализацию сортировки массива со структурами.
Исходный код не смотрел. Но понимаю о чем вы говорите. Доводы правильные выводы ложные. Что снегопат, что инструменты разработчика, растут из закрытого когда платформы, точнее штатной IDE, что как бы следствие того, что продукт коммерческий. Была попытка переехать на эклипс, но она какая-то не о чем. Сама платформа то тут причем, ну если не брать в расчет то, что конфигуратор, это часть платформы.
А я говорю, что есть операции с которыми легко справляются мобильные телефоны на стороне клиента и гонять данные между сервером и клиентом нет смысла. Сортировка небольшого массива одна из таких операций, железо позволяет - платформа нет. Значит причина в платформе.
Не знаю, вам виднее конечно, считается нормальным или нет сортировать 50к структур на мобильном устройстве клиента. Тут просто архитектура предполагает, что вы будете это делать на сервере. Можно упереться рогом в "я хочу и мне все равно". Но платформа то тут причем?
Про тормознутость Python'а полно информации в интернете. То, что разработчики ничего с этим не делают - плохо. Как показало время, даже движок JavaScript удалось создать достаточно быстрым. Дело в программистах.
Причем питон настолько тормознутый, что на нем писали ютуб и линкед. Да, какие то движки быстрее какие-то медленнее. Это объективный факт, тем не менее выпилить питон из какого нить убунту, почти никак. Программисты так страдают, что очень много на нем пишут.
Перечислить кому, 1С?
Перечислить как хоть какие-то аргументы, кроме того, что у вас плохо получилось написать свою реализацию сортировки массива со структурами.
Вы смотрели исходный код "Инструментов разработчика" Сергея Старых? ...
Исходный код не смотрел. Но понимаю о чем вы говорите. Доводы правильные выводы ложные. Что снегопат, что инструменты разработчика, растут из закрытого когда платформы, точнее штатной IDE, что как бы следствие того, что продукт коммерческий. Была попытка переехать на эклипс, но она какая-то не о чем. Сама платформа то тут причем, ну если не брать в расчет то, что конфигуратор, это часть платформы.
(22)
(22)
Если перечитаете мою "портянку", то в ней я как раз удачно решил свою задачу. Моя сортировка 3,5 секунды против метода сортировки ТЗ на стороне сервера, которая показала те же 3,5 секунды. Моя реализация не требовательна к памяти и не требует перекидывания данных туда сюда. Но решение задачи сортировки это всего-лишь пример на котором отчетливо виден серьезный баг оптимизации интерпретатора кода 1С, который выполняет код с разной скоростью в зависимости от количества переводов строк и вызовов функций. Видимо идеальный случай для 1С это написать весь код конфигурации в одну строку.
(22)
"Инструменты разработчика" не растут из закрытого кода платформы, т.к. не внедряются в процесс 1С. Внешние компоненты, скрипты и утилиты используются там для добавления функционала отсутствующего в 1С.
Факт того, что продукт коммерческий не делает его хорошим. Вот например что мешало разработчикам 1С сделать такие полезные вещи как:
- возможность администрирования кластера из конфигуратора. Хотя бы завершения сеансов сделать оттуда, а не из глючной во всех отношениях оснастки;
- возможность скрывать кнопку "Конфигуратор" у пользователей, которые вынуждены пользоваться толстым клиентом, но если случайно туда нажмут и уйдут пить кофе оставив окно авторизации, то ни один программист не войдет уже в конфигуратор пока не убьет сессию нерадивого пользователя;
- сделать альтернативный вариант COMConnector'у в виде реализации встроенного REST интерфейса, который не будет требовать отдельного веб сервера;
- сделать возможным публикацию веб сервисов из конфигуратора с любой удаленной машины, а не только через удаленный рабочий стол и конфигуратор установленный на том же сервере где запущен Web сервер. Утилита командной строки webinst здорово конечно, но это как администрировать через связку ras/rac - убожество и прошлый век.
Но платформа то тут причем?
(22)
кроме того, что у вас плохо получилось написать свою реализацию сортировки массива со структурами.
Если перечитаете мою "портянку", то в ней я как раз удачно решил свою задачу. Моя сортировка 3,5 секунды против метода сортировки ТЗ на стороне сервера, которая показала те же 3,5 секунды. Моя реализация не требовательна к памяти и не требует перекидывания данных туда сюда. Но решение задачи сортировки это всего-лишь пример на котором отчетливо виден серьезный баг оптимизации интерпретатора кода 1С, который выполняет код с разной скоростью в зависимости от количества переводов строк и вызовов функций. Видимо идеальный случай для 1С это написать весь код конфигурации в одну строку.
(22)
что инструменты разработчика, растут из закрытого когда платформы, точнее штатной IDE, что как бы следствие того, что продукт коммерческий
"Инструменты разработчика" не растут из закрытого кода платформы, т.к. не внедряются в процесс 1С. Внешние компоненты, скрипты и утилиты используются там для добавления функционала отсутствующего в 1С.
Факт того, что продукт коммерческий не делает его хорошим. Вот например что мешало разработчикам 1С сделать такие полезные вещи как:
- возможность администрирования кластера из конфигуратора. Хотя бы завершения сеансов сделать оттуда, а не из глючной во всех отношениях оснастки;
- возможность скрывать кнопку "Конфигуратор" у пользователей, которые вынуждены пользоваться толстым клиентом, но если случайно туда нажмут и уйдут пить кофе оставив окно авторизации, то ни один программист не войдет уже в конфигуратор пока не убьет сессию нерадивого пользователя;
- сделать альтернативный вариант COMConnector'у в виде реализации встроенного REST интерфейса, который не будет требовать отдельного веб сервера;
- сделать возможным публикацию веб сервисов из конфигуратора с любой удаленной машины, а не только через удаленный рабочий стол и конфигуратор установленный на том же сервере где запущен Web сервер. Утилита командной строки webinst здорово конечно, но это как администрировать через связку ras/rac - убожество и прошлый век.
(28) Не в режиме отладки разница будет только на обработку номера строки (которая нужна, чтобы выбросить внятное исключение при сбое по конкретной строке кода). Этой разницей можно пренебречь практически всегда.
Ты про этот комментарий awa?
Только что у себя затестил сравнение миллионного цикла из двадцати присваиваний и их же в однострочном цикле.
Усредненная разница на моем компе - 1400 мс. На миллионном цикле из 20 команд. Итого - 20 000 000. Т.е. накладные расходы на обработку одного номера строки составили порядка 0,07 мкс. Вполне понятная цена за возможность бросить внятный эксепшн. Могла бы быть и поменьше, но "неспешность" 1С общеизвестна (1С на порядок-два медленнее других скриптовых движков, и то если его не провоцировать). Т.е. на типичном цикле, скажем, на 1000 итераций и 20 строках тела цикла накладные расходы составят 1,4 мс.
Ситуации, когда стоит на этом экономить - весьма специфичны.
Ты про этот комментарий awa?
Ну давай посчитаем. В твоем тесте цикл выполняется миллион раз, в варианте шести строк внутри цикла 4 строки, т.е. за время выполнения теста происходит обработка отладочного кода (1) четыре миллиона раз. Именно этих четырех миллионов вызвовов команды (1) нет в варианте с одной строкой. Уходит на это примерно пол-секунды (на моем рабочем компе разница между тестами 0.4 секунды). В обычной жизни для вывода пользователю результатов запроса из БД надо выполнить не более нескольких тысяч строк (с учетом всех циклов), что на три порядка меньше, чем в тесте. Т.е. способом "пишем всю программу в одну строку" ты будешь ловить миллисекунды.
Только что у себя затестил сравнение миллионного цикла из двадцати присваиваний и их же в однострочном цикле.
Усредненная разница на моем компе - 1400 мс. На миллионном цикле из 20 команд. Итого - 20 000 000. Т.е. накладные расходы на обработку одного номера строки составили порядка 0,07 мкс. Вполне понятная цена за возможность бросить внятный эксепшн. Могла бы быть и поменьше, но "неспешность" 1С общеизвестна (1С на порядок-два медленнее других скриптовых движков, и то если его не провоцировать). Т.е. на типичном цикле, скажем, на 1000 итераций и 20 строках тела цикла накладные расходы составят 1,4 мс.
Ситуации, когда стоит на этом экономить - весьма специфичны.
(33) В моей реализации quicksort в цикле 55 строк. Выполняется он больше 1 млн. раз. В одну строку выполняется 3,5 секунды, в развернутом виде 1,5 минуты. Если признать проблему, то есть 2 пути её решения:
1. Оптимизации движка интерпретатора
2. Добавление специфичных функций типа сортировки или поиска по регулярным выражениям в движок.
1. Оптимизации движка интерпретатора
2. Добавление специфичных функций типа сортировки или поиска по регулярным выражениям в движок.
(35) Что-то многовато выходит. По моим замерам даже на 10 млн должно быть более чем в два раза меньше.
Но для релизации наколенных квиксортов и регэкспов платформа точно не предназначена :)
Разработчики сознательно не заморачиваются с оптимизациями движка, т.к. они не имеют смысла на фоне профиля нагрузки типового 1С-приложения. Если и будут двигаться, то однозначно по п.2
У тебя проблема в том, что нужна сортировка с хитрым компаратором?
Но для релизации наколенных квиксортов и регэкспов платформа точно не предназначена :)
Разработчики сознательно не заморачиваются с оптимизациями движка, т.к. они не имеют смысла на фоне профиля нагрузки типового 1С-приложения. Если и будут двигаться, то однозначно по п.2
У тебя проблема в том, что нужна сортировка с хитрым компаратором?
(36)
Ну да, по классике -
У тебя проблема в том, что нужна сортировка с хитрым компаратором?
Ну да, по классике -
#include <stdio.h>
#include <stdlib.h>
int compare_ints(const void* a, const void* b)
{
const int *arg1 = a;
const int *arg2 = b;
return *arg1 - *arg2;
}
int main(void)
{
int i;
int ints[] = { -2, 99, 0, -743, 2, 3, 4 };
int size = sizeof ints / sizeof *ints;
qsort(ints, size, sizeof(int), compare_ints);
for(i = 0; i < size; i++)
printf("%d ", ints[i]);
printf("\n");
return EXIT_SUCCESS;
}
Показать
(41) Так ты скажи хоть, как именно тебе нужно твои числа или что там у тебя сравнивать :)
ЗЫ. С чего это числа в строке будут по другому сортироваться? Если ведущие нули учитывать? Другое дело, что сортировка по строке - заведомо медленнее. Но с учетом того, что это встроенная функция, то может и быстрее выйдет.
ЗЫ. С чего это числа в строке будут по другому сортироваться? Если ведущие нули учитывать? Другое дело, что сортировка по строке - заведомо медленнее. Но с учетом того, что это встроенная функция, то может и быстрее выйдет.
(45) Если просто даты отсортировать по возрастанию/убыванию - тогда просто список значений и СортироватьПоЗначению(). Это должно быть быстро.
Если даты в привязке к каким-то структурам данных, тогда структуры в значения списка, а даты - в представления и СортироватьПоПредставлению(). Ессно представления дат надо форматировать в виде "ГГГГММДД ЧЧ:ММ:СС". Но насколько сортировка представлений будет работать быстро/медленно на твоей выборке - уже надо тестить. Тут уже кто пересилит - тормоза движка 1С или тормоза сортировки строк плюс накладные расходы на формирование представлений :)
Если даты в привязке к каким-то структурам данных, тогда структуры в значения списка, а даты - в представления и СортироватьПоПредставлению(). Ессно представления дат надо форматировать в виде "ГГГГММДД ЧЧ:ММ:СС". Но насколько сортировка представлений будет работать быстро/медленно на твоей выборке - уже надо тестить. Тут уже кто пересилит - тормоза движка 1С или тормоза сортировки строк плюс накладные расходы на формирование представлений :)
(48) Не знаю что изменилось, но сегодня квиксорт перестал работать. Ждал 30 минут не дождался, когда он закончится. В субботу все работало, данные не менялись... Да и ТЗ сортировалась не 66 секунд, а 3.5 сек.
Кстати интересное наблюдение насчет СпискаЗначений. Несмотря на то, что я делал сортировку по возрастанию, метод ВыгрузитьЗначения() вернул мне массив отсортированный по убыванию. Соответственно когда я отсортировал по убыванию, ВыгрузитьЗначения() вернуло массив отсортированный по возрастанию...
Кстати интересное наблюдение насчет СпискаЗначений. Несмотря на то, что я делал сортировку по возрастанию, метод ВыгрузитьЗначения() вернул мне массив отсортированный по убыванию. Соответственно когда я отсортировал по убыванию, ВыгрузитьЗначения() вернуло массив отсортированный по возрастанию...
(48) В общем провел эксперимент немного в других условиях. Поставил платформу 8.3.11, перешел с базы PostgreSQL обратно на MSSQL, переписал алгоритм QuickSort. Сделал замеры:
QuickSort - 30 сек, minified версия (в одну строку) - 3,5 сек.
СписокЗначений - 144 мс.
ТаблицаЗначений - 549 мс.
QuickSort - 30 сек, minified версия (в одну строку) - 3,5 сек.
СписокЗначений - 144 мс.
ТаблицаЗначений - 549 мс.
(21)
Такие проблемы действительно были, но бОльшая часть из них уже решена. О ложных срабатываниях антивирусов уже давно не сообщали. Про подвисание интерфейса не понял. Внешние компоненты, не имеющие 64-разрядной версии, большей частью используются в функциях вспомогательного плана. Да и смысла большого использовать 64-разрядное клиентское приложение в большинстве случаев нет.
работает не всегда стабильно, начиная от ложных срабатываний антивируса, подвисанием интерфейса и заканчивая несовместимостью компонент с разрядностью клиента (32 или 64 бита)
Такие проблемы действительно были, но бОльшая часть из них уже решена. О ложных срабатываниях антивирусов уже давно не сообщали. Про подвисание интерфейса не понял. Внешние компоненты, не имеющие 64-разрядной версии, большей частью используются в функциях вспомогательного плана. Да и смысла большого использовать 64-разрядное клиентское приложение в большинстве случаев нет.
(53)
Например в редакторе хранилищ настроек или в списке пользователей, где можно зайти под выбранным пользователем подменив на время пароль. При работе со списком - поиск, отбор, прокрутка. Сам диалог, где ставятся галочки про подмену пароля и ожидания завершения сессии. Странным образом зависает периодически и как-будто меняет размеры.
А также подвисания при выборе типа значения параметра в консоли запросов.
Могу записать небольшой видео ролик демонстрацию, если захотите разобраться. Я тоже заинтересован в улучшении инструментов.
Про подвисание интерфейса не понял
Например в редакторе хранилищ настроек или в списке пользователей, где можно зайти под выбранным пользователем подменив на время пароль. При работе со списком - поиск, отбор, прокрутка. Сам диалог, где ставятся галочки про подмену пароля и ожидания завершения сессии. Странным образом зависает периодически и как-будто меняет размеры.
А также подвисания при выборе типа значения параметра в консоли запросов.
Могу записать небольшой видео ролик демонстрацию, если захотите разобраться. Я тоже заинтересован в улучшении инструментов.
(12)
почему-то именно это лично мне и хочется сказать: "Да, это нормально, что перфоратором закручивать болты несколько дольше, чем гаечным ключом". И "Да, 1С не лучшая платформа чтобы писать быструю сортировку".
Вот если бы вы обозначили задачу целиком, был бы разговор по существу. А так - сферическая сортировка в вакууме.
И вы хотите сказать, что это нормально? Решать задачу, которая решается на С++ за 5 минут с такими танцами и бубном?
почему-то именно это лично мне и хочется сказать: "Да, это нормально, что перфоратором закручивать болты несколько дольше, чем гаечным ключом". И "Да, 1С не лучшая платформа чтобы писать быструю сортировку".
Вот если бы вы обозначили задачу целиком, был бы разговор по существу. А так - сферическая сортировка в вакууме.
(17)
1С в принципе не лучшая платформа для очень многих вещей. Дело даже не в сортировке. Я писал на многих языках программирования, такого скудного функционала, тормознутости и откровенных багов как в 1С нигде не видел. Вместо того, чтобы взять лучшие практики разработки и доработать платформу, фирма 1С штампует конфигурации. Самое печальное то, что в итоге до них это доходит, о чем видно в "Зазеркалье", но с огроооомным лагом.
1С не лучшая платформа
1С в принципе не лучшая платформа для очень многих вещей. Дело даже не в сортировке. Я писал на многих языках программирования, такого скудного функционала, тормознутости и откровенных багов как в 1С нигде не видел. Вместо того, чтобы взять лучшие практики разработки и доработать платформу, фирма 1С штампует конфигурации. Самое печальное то, что в итоге до них это доходит, о чем видно в "Зазеркалье", но с огроооомным лагом.
(25) Это не спасет ровно никак. Будет все-равно вызов сервера. Объект ДанныеФормыКоллекция предназначен лишь для целей порционной загрузки данных на клиент с сервера. Т.ч. если создать реквизит формы ТаблицаЗначений, то физически данные будут лежать и сортироваться на стороне сервера. Мы же стремимся к минимизации вызовов сервера.
В целях оптимизации объема данных, передаваемых между клиентом и сервером, платформа 1С:Предприятие по-особому организует передачу объектов формы типа ДанныеФормыКоллекция. Данные таких объектов передаются определенными порциями таким образом, что новые порции данных передаются с сервера на клиент только по мере обращения к этим данным на клиенте. Необходимо учитывать эту особенность при разработке форм, т.к. в противном случае, код формы может приводить к излишним неявным серверным вызовам, инициируемым платформой.
В целях оптимизации объема данных, передаваемых между клиентом и сервером, платформа 1С:Предприятие по-особому организует передачу объектов формы типа ДанныеФормыКоллекция. Данные таких объектов передаются определенными порциями таким образом, что новые порции данных передаются с сервера на клиент только по мере обращения к этим данным на клиенте. Необходимо учитывать эту особенность при разработке форм, т.к. в противном случае, код формы может приводить к излишним неявным серверным вызовам, инициируемым платформой.
(9)Я думаю это повод для хорошей, большой статьи. Где вы опишете все ваши страданиями, приведете код, покажете как бы вы решали это в С++ и расскажете аргументировано почему же вы страдаете когда работаете с 1С. Если проблемы действительно серьезные, то статья привлечет много внимания в том числе как следствие есть шанс, что и внимание разработчиков платформы 1С.
(7) ой , черная реклама тоже реклама... Задолбали эти видосики "я видел что viber прослушивается - расшифровывается , А телега - это лучшее шифрование"...
Да про того же Терешина особо коммерческой рекламы тоже не видели )) Но хайп - есть хайп... И чем больше тут холивара: телеграмм - лучший, телеграмм - говно... , тем больше той же рекламы , которая не реклама.
P.S. Сестра в германии говорит, что и про вайбер там особо не слышат, а про телеграм и не знает... Им же просто пофиг на РКН.
Да про того же Терешина особо коммерческой рекламы тоже не видели )) Но хайп - есть хайп... И чем больше тут холивара: телеграмм - лучший, телеграмм - говно... , тем больше той же рекламы , которая не реклама.
P.S. Сестра в германии говорит, что и про вайбер там особо не слышат, а про телеграм и не знает... Им же просто пофиг на РКН.
(34)Черная или зеленая, когда Дуров анансировал телеграмм, он сказал вот вам исходный код протокола, кто сможет взломать или доказать уязвимость, получит 10к$. За призом никто не пришел. Это о чем то говорит? Я не знаю, что там с вайбером или ватсаппом. Но к ним априори меньше доверия хотя бы только по той причине, что никто из них себе такого позволить не может. И да половина моих знакомых не слышали про телеграмм. Они из России. И им тоже пофиг на РКН.
(2) под все имеющиеся платформы, да со сквозным шифрованием, да с API и всеми сервисами, которые сейчас на нем есть? Да потом еще добиться той аудитории, что есть у телеграма, и чтобы поделка не упала сразу, а хоть какое-то время справлялась с нагрузкой? Чет вы, батенька, балаболите. Написать, конечно, можно все, но меня терзают смутные сомнения, что это сделает любой школьник.
(2) вас не беспокоит что телеграмм на момент привлечения инвестиций как бы... ну.. УЖЕ работал, то есть по сути школьник написал на коленке, раскрутил в своем дворе (РФ и СНГ) а потом и по соседним дворам (по миру), при этом не прогнулся ни перед гопниками (РКН), ни перед учителем который предлагал обменять его на 12 в семестре (когда его пытались купить за 4 ляма), ни на уговоры бабушки "рассказать чо там марь петровна про меня гадости пишет" (закрытые ключи).
И когда он привлек в приложение тыщщи людей, сделал его быстрее чем вайбер и скайп (у меня старый телефон, мне это заметно), добавил кучу плюшек типа встроенного браузера и бесплатного апи (напомню расценки на альфа смс: рассылка через вайбер стоит 1цент за сообщение) - то ну.. как бы.. его продукт начал столько стоить, иначе бы его купили бы не за 1700000000$ а за 20$
Не понимаю с чего вы беситесь только? Это нас с вами вообще никак не касается. Кто то продал свою говноподелку за 3 стармани, а кто то за 1,7лярда у.е. только в первом случае я получу свои 90 рублей по курсу, а во втором - ничего))
И когда он привлек в приложение тыщщи людей, сделал его быстрее чем вайбер и скайп (у меня старый телефон, мне это заметно), добавил кучу плюшек типа встроенного браузера и бесплатного апи (напомню расценки на альфа смс: рассылка через вайбер стоит 1цент за сообщение) - то ну.. как бы.. его продукт начал столько стоить, иначе бы его купили бы не за 1700000000$ а за 20$
Не понимаю с чего вы беситесь только? Это нас с вами вообще никак не касается. Кто то продал свою говноподелку за 3 стармани, а кто то за 1,7лярда у.е. только в первом случае я получу свои 90 рублей по курсу, а во втором - ничего))
По сабжу - телеграмм отличный мессенджер, шустрый и приятно реализованный. В своей команде тоже на него перешли и вообще он мне нравится. Вроде как у него уже 200 млн пользователей и их количество продолжает активно расти. Хотя у вайбера пока в разы больше. Вайбер, в принципе, тоже неплох. Но телеграмм лучше плюс свои плюшки с каналами и ботами. Хотя сравнивать звонки по ним не пробовал. Я вообще для звонков их не использовал.