Felipe Lessa wrote:
> On Tue, Feb 24, 2009 at 4:59 AM, Don Stewart wrote:
> > Looks like the Map reading/showing via association lists could do with
> > further work.
> >
> > Anyone want to dig around in the Map instance? (There's also some patches
> > for
> > an alternative lazy Map serialisatio
Hello,
On Tue, Feb 24, 2009 at 2:36 AM, Don Stewart wrote:
> This idea was the motivation for the new Seq instance, which uses
> internals to build quickly.
>
> Encoding to disk, the dictionary,
>
> $ time ./binary /usr/share/dict/cracklib-small
> "done"
> ./binary /usr/sh
Don Stewart wrote:
> dons:
[...]
> Just serialising straight lists of pairs,
[...]
> And reading them back in,
>
> main = do
> [f] <- getArgs
> m <- decode `fmap` L.readFile f
> print (length (m :: [(B.ByteString,Int)]))
> print "done"
Well, you don't actually
btw, i always thought that it should be a way to overcome any export
lists and go directly to module internals. limiting export is the way
to protect programmer from errors, not security feature, and it should
be left to programmer to decide when he don't need it. compilers
should just be able to
Hello Svein,
Tuesday, February 24, 2009, 3:47:44 PM, you wrote:
>> btw, i always thought that it should be a way to overcome any export
>> lists and go directly to module internals. limiting export is the way
>> to protect programmer from errors, not security feature, and it should
>> be left to
2009/2/24 Bulat Ziganshin :
> Hello Felipe,
>
> Tuesday, February 24, 2009, 11:24:19 AM, you wrote:
>
>> Too bad 'Map' is exported as an abstract data type and it's not
>> straighforward to test this conjecture. Any ideas?
>
> just make a copy of its implementation to test
>
> btw, i always thought
Hello Felipe,
Tuesday, February 24, 2009, 11:24:19 AM, you wrote:
> Too bad 'Map' is exported as an abstract data type and it's not
> straighforward to test this conjecture. Any ideas?
just make a copy of its implementation to test
btw, i always thought that it should be a way to overcome any e
On Tue, Feb 24, 2009 at 5:36 AM, Don Stewart wrote:
> This idea was the motivation for the new Seq instance, which uses
> internals to build quickly.
The problem is that fromDistinctAscList is the best we can do right
now. We don't have something like (|>) that runs in O(1) time, and
trying to in
felipe.lessa:
> On Tue, Feb 24, 2009 at 4:59 AM, Don Stewart wrote:
> > Looks like the Map reading/showing via association lists could do with
> > further work.
> >
> > Anyone want to dig around in the Map instance? (There's also some patches
> > for
> > an alternative lazy Map serialisation, if
On Tue, Feb 24, 2009 at 4:59 AM, Don Stewart wrote:
> Looks like the Map reading/showing via association lists could do with
> further work.
>
> Anyone want to dig around in the Map instance? (There's also some patches for
> an alternative lazy Map serialisation, if people are keen to load maps --
dons:
> wren:
> > Neil Mitchell wrote:
> >> 2) The storage for String seems to be raw strings, which is nice.
> >> Would I get a substantial speedup by moving to bytestrings instead of
> >> strings? If I hashed the strings and stored common ones in a hash
> >> table is it likely to be a big win?
>
Hello Duncan,
Tuesday, February 24, 2009, 5:13:05 AM, you wrote:
> That's actually rather surprising. The system time is negligible and the
yes, this looks highly suspicious. we use 1.5 seconds for 1.3 mb file,
and 0.3 seconds for 0.3 mb file, so it looks like readFile monopolize
cpu here, being
On Mon, 2009-02-23 at 17:03 -0800, Don Stewart wrote:
> Here's a quick demo using Data.Binary directly.
[...]
> $ time ./A dict +RTS -K20M
> 52848
> "done"
> ./A dict +RTS -K20M 1.51s user 0.06s system 99% cpu 1.582 total
>
>
> Ok. So 1.5s to decode a 1.3M Map. There may be be
wren:
> Neil Mitchell wrote:
>> 2) The storage for String seems to be raw strings, which is nice.
>> Would I get a substantial speedup by moving to bytestrings instead of
>> strings? If I hashed the strings and stored common ones in a hash
>> table is it likely to be a big win?
>
> Bytestrings shou
14 matches
Mail list logo
