add ByteString version of frames

[codygman]

I'm not sure if you even find this useful, but for my use case I can assume ascii a lot and using ByteString gives a nice speedup.

I couldn't think of a good way to do this (backpack adoption is way too far out) so I pretty much just made a copy and replaced stuff with bytestring implementations.

[acowley]

I haven't yet had a chance to dig in to this. I really like the idea of better supporting ByteString and want it to happen. Is this wholesale duplication of everything necessary? I hope it can be boiled down to an appropriate type parameter and user-facing functions that fix that parameter to Text or ByteString for the "raw data" type. Of course, hopes don't compile even if they do type check, so it'll need to be sussed out with real code.

[codygman]

It is almost fully duplicated but I got lazy and converted text to bytestring for one thing. I lost as much interest after profiling and not seeing huge differences. I'm using the rapid library to keep huge frames in memory now though, and the space savings might be compelling enough for me to put effort towards this again. I agree on hoping it can just be a type parameter, but wanted a quick POC to see if this would help my use case. I'm also converging on some good, fast, and small memory footprint date handling using UNIX timestamps and the unix-time library. Though it may be worth it to me to only store dates as a pure Int64 stored in an unboxed vector since I'm running out of RAM. Though grants minus any of my changes is very densely packed, kudos on that. To be honest I'd like to rewrite Thyme to use Text (maybe bytestring, but conversions worry me) and then use that library. I'd also like like a different optional time type that just uses an Int64 rather than unlimited precision integer. Really though, I need to do a lot more profiling and probably looking at core to make sure I'm not spinning my wheels. Thoughts? On Jan 6, 2017 3:07 PM, "Anthony Cowley" <[email protected]> wrote: I haven't yet had a chance to dig in to this. I really like the idea of better supporting ByteString and want it to happen. Is this wholesale duplication of everything necessary? I hope it can be boiled down to an appropriate type parameter and user-facing functions that fix that parameter to Text or ByteString for the "raw data" type. Of course, hopes don't compile even if they do type check, so it'll need to be sussed out with real code. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANyN7gOyYtpO4Lpqy48fBmzEj8NPShhks5rPq0SgaJpZM4LWDdY> .