Comments (9)
I created: https://github.com/hasufell/shortbytestring
It's also on hackage: https://hackage.haskell.org/package/shortbytestring
Reviews welcome. It is currently used in the abstract-filepath library, which is WIP and will heavily rely on it.
from bytestring.
I/O functions that may block (and therefore are marked safe
) typically require pinned memory afaik, so I don't think we can avoid the allocation & memcpy anyway...
from bytestring.
Even at a time when the STUArray is frozen and has left the ST monad?
from bytestring.
@hce I think I might but it's not going to be easy, since System.IO.hPutBuf
uses Ptr
so you'd have to go deeper into the internals. Also, are you sure this is your performance problem? Writing a very short string into a handle is not going to be quick anyway since we have to take the Handle
lock and do various other checks. If you're writing a lot of ShortByteString
then you're much better off using the bytestring Builder
which builds up big chunks and can flush them in one go (often bypassing the Handle
buffer entirely).
from bytestring.
What I need the mutable array for is the deflate algorithm that I'm implementing. I'm open to alternative suggestions for how to best implement this. :)
It is not the only bottleneck, but the conversion does appear to take a non-negligible amount of time.
Do you think "converting" the individual Word8 values to a Builder would be more efficient than the memcpy of ShortByteString into ByteString?
from bytestring.
Do you think "converting" the individual Word8 values to a Builder would be more efficient than the memcpy of ShortByteString into ByteString
No, a memcpy is as fast as it gets. Using a builder is also copying, just slower.
from bytestring.
So, I have to say I'm back in a state of confusion. I'm not really clear what you're doing, or what you think would make things faster. We should have some clear statement of a problem and a plausible looking solution before anyone implements anything here.
from bytestring.
I propose doing the opposite: adding processing functions to ShortByteString
, usually i have a workflow like: IO ByteString ---> Some Parser ---> DataStructure Contain ShortByteString
, but if i want to further process these DataStructure
s, i got stuck since there's not so many combinators out there.
One problem is the combinators explosion, a possible way i can think of is to use type ShortByteString = Vector Word8
, and reuse all the good things in Data.Vector.Unboxed
, or maybe it's better to make a new package?
from bytestring.
I'm afraid that expanding ShortByteString
API will inevitable raise a question about Char8
interface and lazy ShortByteString
(at this point it won't be short anymore, but rather a ByteString
backed by ByteArray
, cf. #193). And we are quite bad at providing a consistent API even for four existing ByteString
flavours (#289).
from bytestring.
Related Issues (20)
- bytestring-0.11.5.1 (ghc-9.4.6) fails to build on Fedora HOT 4
- isValidUtf8 is broken HOT 4
- Compatibility with GHC's JavaScript backend HOT 1
- Overhaul Data.ByteString.Builder.RealFloat HOT 5
- Float and Double standard with precision 0 outputs incorrectly HOT 2
- Positive and Negative Zero Print Incorrect Precision
- Guidelines for using with WriterT HOT 2
- RealFloat Zero Padded Exponent HOT 7
- Faster Printing for Known Normal and Subnormal IEEE754 Floating Point Values
- Broken links in haddocks of `ShortByteString` HOT 1
- Audit `foreign import ccall` types
- Drop support for GHCs older than 8.4 HOT 1
- Add a splice of ShortByteString builder
- 0.12.1.0 fails to build on darwin aarch64 with GHC-8.10.7 HOT 13
- Create strict bytestrings from FixedPrim with zero copy HOT 6
- Lazy `zip` is stricter than expected
- unsafeUseAsCString(Len) may return a NULL pointer. HOT 9
- Document that `Data.ByteString.Lazy.appendFile` is not threadsafe.
- Eq and Ord for Builder
- Offer conversion with `Natural`. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bytestring.