[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [Gnash-dev] Re: Bitwise stream reading performance

From: Udo Giacomozzi
Subject: Re[2]: [Gnash-dev] Re: Bitwise stream reading performance
Date: Tue, 28 Aug 2007 09:32:49 +0200

Hello strk,

Monday, August 27, 2007, 11:22:38 PM, you wrote:
>> That won't work as the read-ahead cache would load data (= steal data)
>> from tu_file which instead should be read by these special tag
>> loaders.

s> tag loaders which will use the underlying stream will NOT enable
s> the cache.. 

The problem are tag loaders *before* those tag loaders you talk about.
"Stream" will read ahead data for a tag that reads bitwise and may
read into a tag that will not use the cache.

You said that "stream" knows the length of a tag. Now this could solve
that problem but I'm still not very happy with this multi-level access
design. As it makes things more complicated I'd go this way only if
redesigning into a more straightforward is even more complicated.

>> I fear we won't be able to implement any kind of caching mechanism
>> unless *everything* uses "stream" to load data or bit-reading is
>> implemented in tu_file itself. The latter case is the worst thing I
>> can imagine.

s> I'd still research on externalizing the cached-bits-reader into a specialized
s> class.

Again, can you explain what real benefit? The cache implementation
itself won't be big, just a handful lines of code. IMHO it's
counterproductive to use a special class for this. The stream would
become a *wrapper* for the cache class...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]