• PG2 benchmarks, part 2

    Table of Content

    In the previous post, I was measuring bare query/execute/copy functions of the library. Although it’s useful, it doesn’t render the whole picture because it’s unclear how an application will benefit from faster DB access.

    This post covers the second group of benchmarks I made: a simple HTTP server that reads random data from the database and responds with JSON. The benchmark compares PG2 and Next.JDBC as before.

    Introduction

    Some general notes: the server uses Ring Jetty version 1.7.1, JVM 21, Ring-JSON 0.5.1 for middleware. The handles are synchronous. The application uses connection pools for both libraries, and the pools are opened in advance when the server gets started. The maximum allowed pool size is 64. HTTP requests are sent by the ab utility with different -n and -c keys; the -l flag is always sent.

    Read more →

  • PG2 early announce and benchmarks, part 1

    TL;DR: https://github.com/igrishaev/pg2

    Table of Content

    Introduction

    During the last year, I was working on PG — JDBC-free PostgreSQL driver in pure Clojure. By purity it means, there is only a TCP socket to read and write bytes according to the official PostgreSQL protocol, and nothing more.

    It was fun: the very idea of implementing something low-level in Clojure was a challenge. I’ve made a series of tricks to squeeze the performance: mutable collections in favour of Clojure’s ones, special macros to traverse collections using Iterator and .forEach, and so on. After all, my driver was about 1.5 times slower than Next.JDBC, and I still think there is room for further improvement.

    One may ask what is the point of making a driver from scratch in 2024. The reason is, I’m still missing plenty of Postgres features when working with it from Clojure. Namely:

    • no built-in JSON support. In every project, I’ve got to extend some protocols with PGObject, encode and decode the JSON manually;

    • no COPY support. In Postgres, COPY IN/OUT is one of the best features I can remember. But there is no built-in CSV nor binary encoding, for example.

    • Poor time support: selecting a timestamp returns an instance of java.sql.Timestamp which is based on java.util.Date: a mutable object deprecated in Java 1.1.

    • Poor array support: only a certain number of types, no multidimensional arrays, etc.

    • No built-in connection pool.

    Today I deprecated the PG project in favour of PG2. This is a successor of PG(one), my second attempt to make a JDBC-free driver for Postgres. This time around, it’s written completely in Java with a thin Clojure layer. I’ve made some benchmarks and it looks like PG2 2-3 times faster than Next.JDBC. There is no documentation yet, only integration tests that cover plenty of cases (I borrowed the old tests and improved then). Although the documentation is highly required, I could not wait to announce PG2 and share the benchmarks.

    How the benchmarks were made

    I’ve got three Mac devices with core i5, i9, and ARM M1 processors. On each device, I’ve got PostgreSQL installed. All the settings are default, no changes are made. JVM is version 21 although the 16th is the minimum version. The benchmarks are made with Criterium version 0.4.6.

    There are two types of benchmarks, actually. In the first group, I measure query/execute functions using the Criterium framework. In the second group, I’m running a simple HTTP server using Ring + Jetty + JSON and measuring requests per second with Apache Benchmark (ab). For each test, I show the source code with a chart and comments.

    The source code of benchmarks can be found in the repository.

    Read more →

  • Предновогоднее

    Этот пост — просто чтобы сказать что-нибудь хорошее перед Новым годом.

    Спасибо всем, кто меня читает. Я отключил аналитику и не знаю, становится ли читателей больше или меньше. Хочется верить, что кому-то все еще интересны мои статьи. Надеюсь, это сохранится и в будущем.

    Недавно я перенес партию заметок и Телеграма в блог, и в комментариях упрекнули, что много нытья про плохой софт. Я перечитал и понял, что это так. Давно заметил: находить недостатки в чужой работе легко. Можно взять айфон и найти сотню недостатков в интерфейсе. Это обеспечит блог постами на год вперед, но кому интересен поток жалоб?

    Поэтому я решил писать меньше о проблемах софта и больше — о чем-нибудь другом. На ум приходят такие темы:

    • большой пост про майнинг с картинками. Я майнил два года, были фермы, горы железа и прочего. Год назад я вышел из майнинга и теперь могу рассказать о нем.

    • драйвер для Постгреса. Недавно я переписал его на Джаве и теперь он в три раза быстрее, чем next.jdbc Шона Корфилда. Пишу и сам в это не верю. Но многое нужно поправить, прежде чем выкатить релиз.

    • пост про 1С, на котором я писал года три-четыре еще в Чите. Меня задевает, когда про 1С рассуждают те, кто знает его со слов свата кума сестры. Расскажу, как за вечер сделать на 1С то, что фронтендеры пилят месяцами.

    Всем удачи и добра, увидимся в новом году.

  • Плеер в Ютубе

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

    Пример: если щелкнуть по видео, фокус будет на временной шкале. Пробел ставит видео на паузу. Если кликнуть по динамику, выключится звук, и фокус окажется на виджете звука. Нажимая пробел, вы будете включать и выключать звук.

    Если кликнуть по кнопке субтитров, пробел переключится на их включение и выключение. Аналогично с гайкой и выпадашкой из нее.

    Ясен хрен, так быть не должно. Пробел должен отвечать за что-то одно, а не все разом в зависимости от того, где сейчас фокус. Это мышление кодера: да, плеер сложный и логично, что он состоит из компонентов. Но какое мне дело как пользователю? Представьте радиоприемник, где у кнопок разные функции в зависимости от угла к северу или фазы Луны. А для фронтендера это — обычное дело.

    Наконец, попытайтесь объяснить эти мульки пожилому родственнику или ребенку, которого вы усадили смотреть Ютуб. И в последний момент черт дернул вас кликнуть по виджету звука. В итоге фокус остался на нем, и каждый раз, когда родственник жал пробел, чтобы поставить на паузу, он выключал звук.

    Я уже говорил, что нам не везет с фронтендерами. Почему-то они не могут сделать нормальный интефейс, хоть в Гугле, хоть Амазоне, получая при этом космические деньги.

    Чтож, подождем.

  • Наблюдение

    Обновить программу, которая долго просит обновиться, в надежде, что она оставит тебя в покое – то же самое, что дать денег алкашу. Через какое-то время он придет снова, но будет просить настойчивее.

    Нужно расстаться раньше этого.

  • Две проблемы

    Говорят, в программировании две проблемы: инвалидация кэша и именование переменных. Не знаю, я никогда не испытывал с этим проблем. Чтобы не сбрасывать кэш, просто пиши без кэша. Проще оптимизировать SQL-запрос, чем возиться с условным Редисом.

    Переменные называй как хочешь, главное — не терять темп при написании кода. Если я думаю над именем больше секунды, то пишу foo и bar. Когда код готов, становится ясно, во что их переименовать.

    Истинные две проблемы программирования другие.

    Первая — программист закладывает абстракции там, где не следует. Иными словами, готовится к тому, что никогда не произойдет. Например, делает наследование из трех классов или внедряет ОРМ на случай переезда на другую базу. И никогда не переезжает.

    Вторая проблема — наоборот: программист не оставляет шанса поправить его код. Скажем, сервис должен вернуть список сущностей, и программист честно отдает массив в JSON. И теперь нужно добавить в ответ какую-то мету, но сделать это нелья — у нас вектор, а не мапа. Приходится исправлять на мапу и выносить мозг клиентам, чтобы поправили у себя.

    Как только первое и второе правила согласуются с реальностью, жить и работать становится проще.

  • Вещи, которые должны были сделать жизнь лучше (1)

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

    Уведомления

    Идея была хорошая: программа, даже если она не запущена, показывает текст о том, что случилось. Но уведомления приняли лавинообразный характер. Представьте, что творится с телефоном, где 40 приложений, и каждое шлет уведомления. Большая их часть бессмысленна и нужна только затем, чтобы пользователь открыл программу. Поэтому первое, что делает нормальный человек при покупке телефона — откючает весь этот зоопарк.

    А есть еще уведомления в браузере! Кто их там включает в здравом уме, не представляю.

    Обновления

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

    Редкая программа обновлятся молча. Чаще всего нам показывают модалки, которые нельзя скрыть. Никого не волнует, что обновление одной программы сломало другую. Обновления рушат процессы, вынуждают людей простаивать, потому что ноут ушел в обновление. Скрипт, который стабильно работал полгода, упал из-за нового пакета.

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

    Голосовые меню

    Верю, что за ними стояли благие намерения: дозвонился человек, а мы ему и курсы валют расскажем, и расписание отделений, и ставки по вкладам — только нажми кнопку. Проблема в том, что чаще всего человек звонит с одной целью — обсудить вопрос с другим человеком. Голосовое меню становится препятствием, и единственное, чего хочет клиент — чтобы его поскорей соединили с оператором.

    Например, десять вечера, ребенок заболел. Я звоню в аптеку, чтобы узнать, есть ли то, что нужно. А там номер 8-800: сначала здравствуйте, потом свежие предложения, перечисление пунктов меню. Оператор поддержки сидит в Туле за тысячу километров. Какая от него может быть помощь? Поэтому я звоню только в аптеки с городским номером.

    Забавно, что лет двенадцать назад я делал голосовое меню для Энергосбыта в Чите. Находил это очень важным и полезным для абонентов.

    Синтез речи

    С обработкой речи ситуация спорная. С одной стороны, прикольно управлять Алисой: включать музыку, спрашивать погоду и всякие мелочи. С другой стороны, технологии речи привели к телефонному спаму. Раз в пару дней звонок из банка, где заскриптован разговор сотрудника, предлагающего кредит. Сделано очень реалистично: если не прислушаться, можно разговаривать с машиной, как с живым человеком. Эту технику переняли различные мошенники, и их жертв стало больше.

    Фирм, которые предлагают телефонный спам, совсем немного, буквально пять. Одна из них находится в Воронеже. У нас на митапе выступал ее основатель. Если отбросить мыльную формулировку “оказание услуг по информированию населения посредством телефонной и сотовой связи”, то останется то, ради чего фирма и создавалась — спам. Так что имейте ввиду: когда вам звонит робот с предложением списать долги, велика вероятность, что это дело рук одного хорошего воронежца.

    (продолжение следует)

  • Картинки в Телеграме

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

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

    Почему нельзя показать абзац текста, картинку, снова абзац, снова картинку и так далее? Я бы с радостью заплатил за это. Тут либо маркетинг, либо какие-то тараканы в голове, потому что технических ограничений я не вижу.

    Вот и получается, что пост с картинками проще сверстать в Телеграфе и кинуть ссылку, чем бодаться с Телеграмом. Редкий случай, когда фирма делает костыль для самой себя.

    Все это очень странно.

  • Your Steam Year In Review

    Проблемы с письмами бывают не только у Госуслуг или Почты России. Стим тоже грешит. Прислал письмо с темой “Your Steam Year In Review 2023 is Here!”. Там все такое красивое, и жирная кнопка “See your review”:

    Жму, а там:

    Что хотел сказать автор? Ваше ревью не пошарено. Что делать дальше? Надо его пошарить? Как? Залогиниться? Зайти по ВПН? Хрен тебя разберет.

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

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

    Знатно налажали они с письмом в этот раз.

  • Роботы + AI

    Почему каждый раз, когда речь идет об искусственном интеллекте, рисуют робота с человеческим лицом? Того самого из “Я, робот” 2004 года в разных вариациях. Глупо и бессмысленно.

    В интернете миллион этих картинок. Вот что открывается по словам “artificial intelligence”:

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

    Гугл выкатил свой AI, и что показывают на презентации? Правильно, женщину- робота:

    Дело в том, что роботы не имеют отношения искусственному интеллекту. Это только в фильмах роботы помогают спасать галактику. А жизни роботы и интеллект — совершенно разные вещи.

    Роботов программируют под узкие задачи, чтобы их поведение было предсказуемым. Если у робота две руки для переноски ящиков, просить его сделать кофе бессмысленно. А то, что мы называем искусственным интеллектом, живет в видеокартах на бесчисленных стеллажах. Он знает, как сделать кофе, но у него нет рук.

    Вообще, эти роботы на картинках выглядят бестолково. Почему из шеи торчат провода и штыри? Их надо спрятать под пластик или какую-то мягкую субстанцию. Что, не хватило материи, чтобы убрать гайки и провода под кожух? Их тела как доспехи — как они будет гнуться? Руки, пальцы — аналогично. В 3D-Максе согнется все, что угодно, а в реальности будут проблемы.

    Там у Gemini на щеке что-то отвалилось, вы поправьте, что ли.

    Нормальных роботов-андроидов я видел только в “Чужих”. Там они мягкие и жидкие, как люди. Вот оно — андроиды должны быть не железными, а жидкими! Только так они могут хоть как-то походить на людей. Фильм “Чужой. Завет” начинается со сцены рождения робота, и там его отливают на стенде. Буквально льют на гибкий каркас. Но и робота в итоге не отличить от человека. Это нормальный робот, а не железный болванчик.

    Наконец, всем, кто мечтает о подобных роботах, рекомендую посмотреть на Дуняшу. Это прекрасно:

Страница 4 из 73