[squeak-dev] Re: squeak XTream
eliot.miranda at gmail.com
Wed Dec 2 19:06:51 UTC 2009
On Wed, Dec 2, 2009 at 10:49 AM, Colin Putney <cputney at wiresong.ca> wrote:
> On 2-Dec-09, at 8:26 AM, Nicolas Cellier wrote:
> Xtream is not functional yet, it is just a three evenings shot.
> At the rate you're going, you'll have caught up to the functionality in
> Filesystem in no time. ;-)
> Especially pipelines are quite tricky with a forked process... I got
>> to rest a bit and think.
>> This kind of implementation natively has good parallelism properties,
>> unfortunately this won't exploit multi-core/processors any time soon
>> in Smalltalk...
> I'm guessing you mean running each stage of the stream in a separate
> Smalltalk Process, using the Pipes and Filters pattern?
> Stephen Pair did some neat stuff with that a few years ago. It's indeed
> tricky. I wonder if it's worth it in this case, though, exactly because
> Smalltalk doesn't exploit multiprocessors. Flow of control inside a stream
> might be complicated without parallelism, but it's probably easier to debug.
> A few month ago, I implemented a simple Wrapper-like scheme, but was
>> not satisfied with end of stream handling. Both EndOfStream exception
>> capture and atEnd tests are expensive when processing elements 1 by 1.
>> Maybe I'll have to turn to such a more simple scheme though.
> I don't understand the issue with EndOfStream exceptions. Throwing and
> catching an exception is expensive, yes, but that should happen only once,
> right? Unless you're setting up exception handler inside a loop, the expense
> of a single exception shouldn't be a problem.
Exception search and delivery is, uh, /expensive/. The cost of propagating
an EndOfStream exception to its defaultAction and returning nil is huge
compared to simply answering an end-of-stream value. So unless one really
wants exception handling one should strive to avoid raising EndOfStream
exceptions at end of stream.
I think in VisualWorks we noticed the extreme expense in the ChangeList
scanner where one is creating lots of streams on strings corresponding to
each chunk. The end-of-stream exceptions on all these streams when doing
something like scanning a changes file would add up to a significant
percentage of the entire parse time. So believe me, it does add up.
> Definitely, we should exchange code/ideas.
> Agreed. We may find that doing parallel development with lots of
> cross-pollination is the best way to explore the design space.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev