не знаю

я не умею придумывать либы

@A64m_qb0 а ты знаешь как фастбилдер работает?

какой из них создавал pipe и сам в себя писал, это не он?

запускает какое-то мутабельное адище в отдельном потоке?

unsafePerformIO - вот это всё?

только вот в таких вот общих чертах

да ансейфперформ это по стандартам обычных байтстрок не адище

сами байтстроки оперируют на два круга ада ниже

import qualified Data.ByteString.Builder.Extra as X

он использует обычный билдер внутри

офигенный код, я не понимаю что там происходит и где

т.е. не могу найти где самое интересное

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

но может это был тупиковый вариант, который потом под нож пошел

ваще круто на самом деле

я пока до конца не понимаю, но мне уже нравится

он создает thunk = unsafeDupablePerformIO $ runBuilder

делает evaluate, WHNF его описывает нужно ли дальше делать или все готово

если дальше, то thunk кидается в отдельный тред который возвращает thunk для хвоста

и отдается консьюмеру

консьюмер сразу может работать с головой

если же он форсит хвост, то он блокируется пока следующий чанк не будет готов

а тред в это время в фоне генерит его и следующий

и похоже нету хранения длины явного

Builder тут это \DataSink -> BuilderState -> BuilderState

как в PutM

он же стейт над парой указателей

-- | This datatype exists only to work around the limitation that 'oneShot' -- cannot work with unboxed argument types.

сколько же туда работы вбухано

@A64m_qb0 а тормозит hPutBuffer т.к. там он не делает чанки большие похоже

вот из обсуждения этой штуки в каком-то тикете на гхц-траке я про фастбилдер и узнал

HandleSink h queueRef -> do cur <- getCur io $ flushQueue h queueRef cur io $ S.hPut h bstr

может если вчитаться то все нормально но похоже что если мы пишем в handle то сразу вбрасываем кусочки

ещё и через S.hPut который сделает доп write на проверку готовности и poll вначале/вконце

похоже, что во всех этой байтстринг инфраструктуре чанки делают только читатели а писатели тупо пишут какие есть

вот тут не совсем

тут читатель делает первый чанк

остальные делает специально обученный тред

я думаю при тормозном консьюмере внешнем это вообще пушка будет

но с неограниченная по памяти

а или я комментарий не понял?

очень интересно, что тут билдер гораздо больше похож на PutM от которого ушли

я комментировал не билдер а обычный байтстринг-мирок

а

да

это кстати проблема

в network-transport tcp тоже вылезало

кстати надо бы через fast-builder попробовать пофиксить

а не network-transport-tcp более низкий

он уже на языке [ByteString] говорит

cloud haskell в продакшене ни у кого рядом нет? а то наш проект временно(?) без нас работает и на нём мне не померять

main :: IO () main = do ws <- BS8.lines <$> BS8.getContents let s = V.map (\v -> case BS8.words v of (a:_) -> a) $ V.fromList ws BSL.hPutStr stdout $ Builder.toLazyByteStringWith 110000 110000 $ foldMap (\suff -> V.foldr (\pref nx -> Builder.byteString suff <> Builder.byteString pref <> Builder.char8 '\n' <> nx) mempty (mkP ws)) s {-# NOINLINE mkP #-} mkP = V.map (\v -> case BS8.words v of (_:b:_) -> b) . V.fromList

какие там импорты?

{-# Language OverloadedStrings #-} {-# OPTIONS_GHC -fno-warn-incomplete-patterns #-} module Main where import qualified Data.ByteString.Char8 as BS8 import qualified Data.ByteString.Lazy as BSL import qualified Data.ByteString.FastBuilder as Builder import Data.ByteString.Char8 (ByteString) import Data.Monoid ((<>)) import qualified Data.Vector as V import GHC.Exts import System.IO main :: IO () main = do ws <- BS8.lines <$> BS8.getContents let s = V.map (\v -> case BS8.words v of (a:_) -> a) $ V.fromList ws BSL.hPutStr stdout $ Builder.toLazyByteStringWith 110000 110000 $ foldMap (\suff -> V.foldr (\pref nx -> Builder.byteString suff <> Builder.byteString pref <> Builder.char8 '\n' <> nx) mempty (mkP ws)) s {-# NOINLINE mkP #-} mkP = V.map (\v -> case BS8.words v of (_:b:_) -> b) . V.fromList

подскажите, в чем прикол использовать кейс в таком виде вместо let case xs of (x:_) -> x let x:_ = xs in x

или даже просто head. Строгость? Потому что тут огромная лямбда заменяется на красивое head . BS8.words

@yellow_apple ^ формально может неудачно получиться как раз на границе

я об этом изначально знал но решил забить уже профиксил

а что там за разделители строк во входном файле?

\s+

это что?

просто у меня хэши не совпадают с референсной версией, боюсь из-за этого как раз

смотрю - строки длиннее на один байт, чем у меня

или даже просто head. Строгость? Потому что тут огромная лямбда заменяется на красивое head . BS8.words

там 2 кейса рядом были, лучше смотрелось вместе

в смысле? хэш ведь для выхлопа проверяется

какая разница, что там на входе

ща поясню

выход - строки разделяются \n

есть ваша референсная прога, которая pypy

и есть моя

вывод у них внешне одинаковый, но хэши разные

\r

убери в таком случае

во входном файле разделители строк \r\n, но могут быть просто \n

в выходном должно быть \n

\r

во, видимо в этом дело

причём даже vim с :set list разницы не видит

референсная, кстати не наша

референсная из исходного наброса

но прогнал через xxd и увидел, что строки на один байт длиннее

референсная, кстати не наша

ща будет ускоренная версия на pypy