You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
typeOffset=InttypeLength=IntnewtypePeek=Peek{runPeek::forallbyte.Ptrbyte->Length->IO (Offset, a) }
then most pointer subtractions and additions could be avoided; for example:
peekStorableTy ty =Peek$\ptr blen ->let needed = sizeOf (undefined::a)
indo
when (needed > blen) $
tooManyBytes needed blen ty
x <-Storable.peek (castPtr ptr)
return (needed, x)
peekToPlainForeignPtr ty len =Peek$\sourcePtr sourceLen ->do
when (len > sourceLen) $
tooManyBytes len sourceLen ty
fp <-BS.mallocByteString len
withForeignPtr fp $\targetPtr ->BS.memcpy targetPtr (castPtr sourcePtr) len
return (len, castForeignPtr fp)
They would move into the Peek monad:
pure x =Peek (\_ _ ->return (0, x))
Peek x >>= f =Peek$\ptr blen ->do
(off, x') <- x ptr blen
runPeek (f x') (ptr `plusPtr` off) (blen - off)
The performance of the two Peek types should be close. But I thought I should ask before setting up the benchmark, in case this approach has already been considered.
The text was updated successfully, but these errors were encountered:
If the type of
Peek
wasthen most pointer subtractions and additions could be avoided; for example:
They would move into the Peek monad:
The performance of the two
Peek
types should be close. But I thought I should ask before setting up the benchmark, in case this approach has already been considered.The text was updated successfully, but these errors were encountered: