buzzword-driven development

какая-то х..ень в чате (

я думаю перейти можно за неделю, понять как правильно писать - за месяц/два

оф гайд хорошо помогает

Хай, народ ) насколько сильно вас будет коробить если например функция, которая называется ParseMessage([]byte) (*Message, error) будет врапиться над буфером не копируя байты? Или назвали бы функцию как-то иначе?

по скользкой дороге идешь

Хай, народ ) насколько сильно вас будет коробить если например функция, которая называется ParseMessage([]byte) (*Message, error) будет врапиться над буфером не копируя байты? Или назвали бы функцию как-то иначе?

плохо, обычно буфер переиспользуется следующим чтением из сокета

Да, идеоматически согласен, весь I/O должен копировать, но там типа тема с малым оверхедом сделать. Короч, задача как сказать разработчику явно об этом...

Сейчас попытаюсь объяснить. Это не классический net.Conn или io.Reader... Буфер создает сама либа, которая читает фреймы из сети. То есть она например создает, допустим 10 Мб и читает, отрезая слайсы сначала (в надежде что GC сама высвободит потом) и есть минимальный порог, например в 10 Кб, когда он пересоздает большой буфер. Потребителю вываливаются готовые сообщения. Многие свойства фрейма врапятся для того, чтобы не копировать.

1) Что создаёт в 10мб? если это выделенный в памяти массив, то gc ничего не освободит если на него есть ссылки хоть откуда

2) как переиспользуется буфер? как ты поймёшь когда готовое сообщение, ссылающееся на буфер уже не нужно?

ты пытаешься сделать zero memory allocation протокол

тогда никаких буферов не будет

Буфер - при чтении. Пересоздание буфера не оставляет в цикле чтения на него ссылок. Ну там пайплайн ) сообщения не должны нигде сохраняться

ну раз не должны =)

выглядит как гаубица с лазерным прицелом в ногу

а смысл не ясен

Да ) ща накидаю код

всё равно ты память выделяешь в итоге

var buf []byte for { if len(buf) < 10000 { buf = make([]byte, ...) } n, err := conn.Read(buf) ... ch <- buf[:n] buf = buf[n: ] }

это чревато проблемами

Да, и вкурсе какие это проблемы

читай в один буфер, который один раз выделил, копируй в сообщения

по скорости будет лучше

Поэтому ищу способ об этом предупредить других разработчиков )

смотри, если ты щас не ответишь на мой вопрос, значит ты делаешь это неверно

вопрос такой, ты измерял производительности и тебя она не устроила и новое решение быстрее?

или это просто измышления?

Да, бенчмарки показывают небольшой, но оверхед ) примерно 20%

Буфер-пул с sync.Pool еще хуже, там почти в два раза почему-то

тебе не нужен синкпул для чтения тут

ты же читаешь в одном треде из сокета

тебе просто нужен буфер байтовый

но если у тебя быстрее работает, то пиши комментарий жирными буквами =)

Ок )

а кто-то тестировал скорость компиляции в 1.9 ?

с этой параллельной компиляцией функций внутри пакета

а кто-то тестировал скорость компиляции в 1.9 ?

прям настоящие замеры до наносекунды?) по ощущениям несколько быстрей стала компиляция, а на сколько даже не интересно

https://github.com/nullbio/abcweb

magic

Фрэймворк на go, у которого: Step 1: Install NodeJS. немного настораживает

Хотел тоже самое написать, товарищ @makarov_igor опередил :)

Фрэймворк на go, у которого: Step 1: Install NodeJS. немного настораживает

Веб крутится вокруг js, что поделать

А что за фреймворк "чай"? Не нагуглил. Оч лёгкий говорят

А что за фреймворк "чай"? Не нагуглил. Оч лёгкий говорят

Cha

https://godoc.org/?q=cha

Что-то не гуглится

+1

Но это же просто роутер?

а справку почитать?

Роутеры в го дислокация повышенного анонизма, извините меня

Package chi is a small, idiomatic and composable router for building HTTP services.

Именно оттуда я и пришел

Что-то много энтропии, давайте с сылки начнем, если кто-то знает о каком пакете речь

you are looking for the big red button framework that makes you happy in one gesture

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

Топикстартер видимо смешал в голове все что слышал, потмоу что по имени фреймворка чай, гуглится только богомерзкий похапе фреймворк с компонентами из симфони: https://github.com/mloberg/Chai

причём снобизм? параграф Features, и, ниже, Examples

chai это для js BDD фреймворк

https://github.com/nullbio/abcweb

Я понял, прост у меня произошел диссонанс после вот этого. Слишком разное понимание фреймворков. Чи это больше роутер с набором хелперов.

речь про https://github.com/go-chi/chi

Я понял, прост у меня произошел диссонанс после вот этого. Слишком разное понимание фреймворков. Чи это больше роутер с набором хелперов.

так и есть, в пхп фреймворк это швейцарский нож

А в джаве - металлургичекий завод полного цикла?)

да там капец

Ребята, вот сижу блог пишу. Такой вопрос: хорошо ли будет хранить текст каждой статьи в бд (со всеми вытекающими: автор, метки и т.д.) и при обращении к какой-либо статье отдавать страницу, на которую контент вываливается из базы, либо лучше просто каждую статью хранить под "неким уникальным идентификатором" и отдавать отдельным файликом?

Ребята, вот сижу блог пишу. Такой вопрос: хорошо ли будет хранить текст каждой статьи в бд (со всеми вытекающими: автор, метки и т.д.) и при обращении к какой-либо статье отдавать страницу, на которую контент вываливается из базы, либо лучше просто каждую статью хранить под "неким уникальным идентификатором" и отдавать отдельным файликом?

ничего не понял.

блин, вродь понятно все.. Ща перескажу по-другому

Есть тип блог. В нем создается статья. Где ее правильно хранить?

А точнее как: в базе, отдельным каким-то html-файлом

есть тип поиск искаробки полнотекстовый в некоторых субд, если он тип нужен - вот тебе причина хранить в базе

Ребята, вот сижу блог пишу. Такой вопрос: хорошо ли будет хранить текст каждой статьи в бд (со всеми вытекающими: автор, метки и т.д.) и при обращении к какой-либо статье отдавать страницу, на которую контент вываливается из базы, либо лучше просто каждую статью хранить под "неким уникальным идентификатором" и отдавать отдельным файликом?

Храни в базе

спасибо :)

в базе, конечно)

а то я все затупливал

хотя нет. Ты же пишешь лабу, наверно? Может у вас там требования на диске файликом хранить. Так что не факт, что в базе лучше)

Не смешно ) Себе пишу как портфолио

нашел красивенький тэймплэйт

понравился, решил запилить

Не смешно ) Себе пишу как портфолио

https://ru.wordpress.com/

Глянь как в вордпрессе сделанно

скопируй идеи