On Thu, May 12, 2005 at 06:41:19PM -0400, Guillaume Germain wrote:
On Thu, 12 May 2005 ben@fuhok.net wrote: I don't think that's correct. Gambit's serialization of continuation is slow, at least in part due to linear lookups being done on all the serialized data when constructing the external representation. Because of the closure representation used in the interpreter a lot of data gets included. The new table facility might be used to help implement this in a more efficient way.
That sounds reasonable. My experience with continuation serialization consists of running the example from the manual.
The example passes the continuation around via a query parameter, not by a hidden form field (though the continuation is included there too).
Note that it doesn't matter if you're using GET whether you pass the continuation in a hidden form field or by tacking it to the URL.
I bet that the example would run very well if the continuation was passed around using POST instead of GET.
Though I think I was way off on the cause of this problem, it does matters a little whether you GET or POST, since there can be a limit to amount of data you can pass with GET. I couldn't get the example to work with IE, maybe for that reason.
It would still be slow. I use continuation serialization to implement process migration in my system and even a "small continuation" will take around a second or two to serialize. When I was including libraries like SSAX or htmlprag, the system was hanging for minutes. At first I thought my program was stuck in an infinite loop, but that's because I was underestimating infinity :)
When I run the example, it is indeed a little slower when interpreted, but only by 1-2 seconds. I'm not experiencing 30+ second delays for whatever reason.
Thanks for clearing that up for me,
Ben