GHC Threads affinity

[Michael Baikov]

Hmmm.... I'll take a look, but from what I see - it uses the same code as
ghc-events for decoding and all the streaming done in a short single commit
- it must suffer the same bug then. It is not a single stream of events,
it's several of them per capability mixed due to caching done by RTS so you
need to decode several streams at once and merge the results.

On Oct 1, 2017 20:43, "Boespflug, Mathieu" <m at tweag.io> wrote:

> You might want to have a look at
> https://github.com/mboes/ghc-events/tree/streaming. Similar to what
> you mention, it uses the "streaming" package for the incremental
> parsing. I ran into an issue with binary that I wasn't able to track
> down: even medium sized buffers make the parsing slower (significantly
> so) rather than faster (my suspicion: something somewhere that should
> be constant time is actually linear).
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 1 October 2017 at 14:34, Michael Baikov <manpacket at gmail.com> wrote:
> > On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu <m at tweag.io> wrote:
> >> Note that the (AFAIK unreleased) version of ghc-events on the master
> >> branch of the upstream repo can parse event streams incrementally, if
> >> that's what you meant.
> >
> > It can but it got some problems. For one the only thing incremental
> > parser can do is to print the output - for everything else old parser
> > will be used and output of that incremental is partially out of order
> > due to the way event blocks are stored. Anyway, I already have my own
> > version that does proper incremental parsing, provides interface with
> > a streaming library and collects some info that wasn't available in
> > the original version. How it's more about shuffling stuff around,
> > cleaning and testing.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/f9578588/attachment.html>