Comments 9
А чем вам boost::beast не угодил?
Boost.Beast слишком низкоуровневый для того, чтобы делать что-то прикладное прямо на нем.
Кроме того, когда мы начали делать RESTinio, Boost.Beast-а еще не было, был какой-то Beast, который еще даже не проходил ревью на включение в Boost. Серьезное внимание и известность Beast получил именно после того, как стал Boost.Beast-ом.
Кроме того, когда мы начали делать RESTinio, Boost.Beast-а еще не было, был какой-то Beast, который еще даже не проходил ревью на включение в Boost. Серьезное внимание и известность Beast получил именно после того, как стал Boost.Beast-ом.
Кстати говоря, чтобы не быть голословным: вот пример того, как одна и та же задача может быть решена на Boost.Beast и RESTinio.
Интересно, гляну обязательно.
Если сможете оставить какой-нибудь фидбек, пусть даже абсолютно субъективным, то для нас это будет весьма полезно. Возможно, это поможет сделать RESTinio лучше в будущем. Ну или мы сами лучше поймем, где преимущества у Boost.Beast, а где у нас.
Посмотрел ваше изделие, оно действительно гораздо высокоуровневее, чем бист.
Код выглядит прилично, чист и аккуратен, даже понять можно, что делает, не особо сломав голову.
Единственно, не отметил практически совсем использования R-value и семантики перемещений.
К примеру, impl/header_helpers.hpp:
куча копирований, никакого перемещения, что, возможно, весьма ускорило бы работу в высоконагруженном приложении. А ведь это делается на каждый HTTP-ответ. Хотя работу по оптимизации проводили, это видно, предварительное резервирование для результирующей строки имеется, что говорит о высоком качестве проработки.
Наверное, я придираюсь. Реально с вашей библиотекой проще. Молодцы!
Код выглядит прилично, чист и аккуратен, даже понять можно, что делает, не особо сломав голову.
Единственно, не отметил практически совсем использования R-value и семантики перемещений.
К примеру, impl/header_helpers.hpp:
...
//
// create_header_string()
//
//! Creates a string for http response header.
inline std::string
create_header_string(
const http_response_header_t & h,
content_length_field_presence_t content_length_field_presence =
content_length_field_presence_t::add_content_length,
std::size_t buffer_size = 0 )
{
std::string result;
...
for( const auto & f : h )
{
result += f.name();
result.append( header_field_sep, ct_string_len( header_field_sep ) );
result += f.value();
result.append( header_rn, ct_string_len( header_rn ) );
}
result.append( header_rn, ct_string_len( header_rn ) );
return result;
}
куча копирований, никакого перемещения, что, возможно, весьма ускорило бы работу в высоконагруженном приложении. А ведь это делается на каждый HTTP-ответ. Хотя работу по оптимизации проводили, это видно, предварительное резервирование для результирующей строки имеется, что говорит о высоком качестве проработки.
Наверное, я придираюсь. Реально с вашей библиотекой проще. Молодцы!
Дело в том что заголовок нужно иметь в виде непрерывной последовательности байт. Вариант отправки множества мелких кусочков не рассматриваем, т.к. scatter/gather io для коротких буферов работает не очень быстро. Вообще быстрее всего работает отправка одного длинного буфера, но в реальности это чаще всего и неудобно и не оптимально.
И выход такой, что хоть сами данные заголовка хранятся в виде string-ов, мы их всех копируем в результирующую строку, размер которой заранее резервируем. Это становится первым буфером в рамках заданного response.
В ситуациях, когда ответ (и его заголовок) создаются на одной нити, а RESTinio c ASIO крутится на другой, то от одной нити к другой в счет заголовка подйет всего один инстанс std::string (память под который выделялась на другой нити, ибо редко какой заголовок влезает в SSO) и для менеджеров памяти для которых освобождать память лучше на той же нити на которой она выделялась, это такая хорошая добавка.
А вообще, да, мувать мы любим и надеюсь умеем ;)
И выход такой, что хоть сами данные заголовка хранятся в виде string-ов, мы их всех копируем в результирующую строку, размер которой заранее резервируем. Это становится первым буфером в рамках заданного response.
В ситуациях, когда ответ (и его заголовок) создаются на одной нити, а RESTinio c ASIO крутится на другой, то от одной нити к другой в счет заголовка подйет всего один инстанс std::string (память под который выделялась на другой нити, ибо редко какой заголовок влезает в SSO) и для менеджеров памяти для которых освобождать память лучше на той же нити на которой она выделялась, это такая хорошая добавка.
А вообще, да, мувать мы любим и надеюсь умеем ;)
«Мувать» тоже увидел :)
ngrodzitski основной разработчик RESTinio, подавляющее большинство кода за его авторством, так что с ним технические детали обсуждать лучше, чем с кем бы то ни было.
Sign up to leave a comment.
Делаем Shrimp еще полезнее: добавляем перекодирование картинок в другие форматы