Permalink
Commits on Dec 8, 2010
Commits on Dec 6, 2010
  1. writes and builders for lossy Latin-1 encoding

      - this is useful for implementing protocols like HTTP
    meiersi committed Dec 6, 2010
  2. factored out unchecked shifts

    meiersi committed Dec 6, 2010
  3. fixed a few benchmarks

      - the blaze-html benchmarks indicate that no speed regression
        happened. Some benchmarks are faster and the bigtable benchmark is
        a bit slower. The new write abstraction is compiled suboptimally
        this may well be the reason for that problem.
    meiersi committed Dec 6, 2010
  4. note that TODO is outdated

    meiersi committed Dec 6, 2010
  5. version bump to 0.2.1.0

    meiersi committed Dec 6, 2010
  6. full compilation working again

    meiersi committed Dec 6, 2010
  7. dropped compatibility with Data.Binary.Builder

      - this layer will be provided separately by the replacement
        of the binary package.
    meiersi committed Dec 6, 2010
Commits on Dec 5, 2010
  1. updated cabal file

      - homepage and issues now point to meiersi github repo
      - source repository is given
    meiersi committed Dec 5, 2010
Commits on Dec 4, 2010
Commits on Nov 30, 2010
  1. remove superfluous benchmarks

      - they slipped in while accepting Jasper's patch for the ' bug.
    meiersi committed Nov 30, 2010
  2. updated changelog

    meiersi committed Nov 30, 2010
  3. version bump to 0.2.0.2

    meiersi committed Nov 30, 2010
Commits on Nov 28, 2010
  1. tried to find a simple test for problem with IO results from branches

      - if several branches do IO and return an unboxable result for the
        following IO action strict in this result, then this result should
        be unboxed for better performance. That doesn't happen in my UTF-8
        encoding code.
    meiersi committed Nov 28, 2010
  2. yet another trie on unboxed continuation calls

      - not successful: twice as slow, than BufRange construction. Sadly, I
        don't know why. Perhaps a GHC expert can explain the cause.
    
        => I'll write the interface of the internal library abstract enough
           such that a change like this would still be possible without
           modifying user code.
    meiersi committed Nov 28, 2010
Commits on Nov 27, 2010
  1. more investigations into bounded writes

      - GHC still insists on packing the pointer returned from a branch. So
        for a single UTF-8 Char write we are slower.
    
      - However, the monoid instance for bounded writes behaves much better
        than the one for writes, as the next pointer computation is combined
        with the actual output, which results in nice straight line code.
    
      => Bounded writes are probably the way to go. It is also easy to
         insulate against later representation changes as the interface can
         be made fully abstract.
    meiersi committed Nov 27, 2010
Commits on Nov 25, 2010
  1. implemented simple wrapper around unboxed addresses

      - however sadly it does not work together nicely with the IO monad,
        as IO expects kind *. Hence, we cannot ensure that the returned
        pointer is passed in unboxed form.
    meiersi committed Nov 25, 2010
  2. generalized write type

      - currently it is a tad slower because it boxes the returned
        next pointer and computes the new address lazily *grr*
    
        Going to change that!
    meiersi committed Nov 25, 2010
Commits on Nov 23, 2010
  1. implemented simple but modular builder driver

      - performance is equal to custom driver currently used in the library
    meiersi committed Nov 23, 2010
  2. new builder construction + enumeration of puts

      - the new builder can be converted with a very minimal cost to a Put
        monad and vice versa => this is the design I'm going for.
    meiersi committed Nov 23, 2010
Commits on Nov 22, 2010
Commits on Nov 21, 2010
  1. benchmarking cost of putBuilder

      - 'putBuilder fromWord8' is 12 times (!) slower than 'putWord8'.
    
         This high cost stems from the fact that the signals of the builder
         need to be translated to the signals of the put monad. Doing this
         for every single Word8 is very expensive. However, if it has to be
         done only once per buffer full signal and the buffers are large
         enough this is no problem at all.
    
         => putBuilder is useful for large builders, but destroys
         performance for too small builders.
    meiersi committed Nov 21, 2010
  2. benchmarking using a packed buffer range for builder

      - use 'BR pf pe' instead of curried 'pf pe' calls for continuation.
        The effect is small but measurable for the Builder (1%).
        Nevertheless, I'd suggest taking it in, as it also reduces the
        chance for coding errors.
    meiersi committed Nov 21, 2010
  3. switched to explicit buffer range constructors

      - using 'BufferRange pf pe' instead of curried 'pf pe' arguments to
        pass along information to the next PutStep. This improves
        performance of append by about (4%).
      - it allows makes the code more clear as now buffer ranges are denoted
        explicitely.
    meiersi committed Nov 21, 2010