
I've run into a problem where it looks like my application crashes with "Error: allocation limit (1024) exceeded for Foreign(Obj/Ptr)" because it's using too many ByteStrings. Does that seem plausible? Can I simply increase the size of that foreign[] array, by several orders of magnitude, to get around this? thanks! Donn Cave, donn@avvanta.com

"Donn Cave"
I've run into a problem where it looks like my application crashes with "Error: allocation limit (1024) exceeded for Foreign(Obj/Ptr)" because it's using too many ByteStrings. Does that seem plausible?
Yes, it seems plausible. nhc98's runtime system has a constant-size table for storing ForeignPtrs.
Can I simply increase the size of that foreign[] array, by several orders of magnitude, to get around this?
Yes, but you will need to recompile nhc98's RTS. (Not hard.) In src/runtime/Kernel/cdata.c, just change the #define'd constant MAX_FOREIGNOBJ, and then (at the toplevel) make runtime make install *However*, you should also be aware that ByteStrings have been optimised for use in ghc, not nhc98. In fact, it turns out that using ByteString is orders of magnitude slower than using plain String, in nhc98. I can't remember the exact factor, but it was something of the order of 60x slower. Regards, Malcolm

Malcolm.Wallace:
"Donn Cave"
wrote: I've run into a problem where it looks like my application crashes with "Error: allocation limit (1024) exceeded for Foreign(Obj/Ptr)" because it's using too many ByteStrings. Does that seem plausible?
Yes, it seems plausible. nhc98's runtime system has a constant-size table for storing ForeignPtrs.
Can I simply increase the size of that foreign[] array, by several orders of magnitude, to get around this?
Yes, but you will need to recompile nhc98's RTS. (Not hard.) In src/runtime/Kernel/cdata.c, just change the #define'd constant MAX_FOREIGNOBJ, and then (at the toplevel) make runtime make install
*However*, you should also be aware that ByteStrings have been optimised for use in ghc, not nhc98. In fact, it turns out that using ByteString is orders of magnitude slower than using plain String, in nhc98. I can't remember the exact factor, but it was something of the order of 60x slower.
For one benchmark. I'd imagine there's others where space is a premium, where it would be no contest to use a packed representation. -- Don
participants (3)
-
Don Stewart
-
Donn Cave
-
Malcolm Wallace