[fpc-devel] Benchmark for FreePascal

Michael Van Canneyt michael at freepascal.org
Mon Dec 12 09:32:48 CET 2005

On Sun, 11 Dec 2005, darekM wrote:

> Michael Van Canneyt napisa(a):
>> On Sat, 10 Dec 2005, darekM wrote:
>>> Hi
>>> I've tested some of benchmark on http://shootout.alioth.debian.org/
>>> I've see that reverse-complement benchmark
>>> <http://shootout.alioth.debian.org/benchmark.php?test=revcomp&lang=all> 
>>> for
>>> FPC is very slow. I discover, that problem is with readln, that function
>>> consume about 90% of time. Because I use it in my program, I implemented 
>>> new
>>> version of reading files. My propositions is add tTextStream to unit 
>>> Classes
>> 1.  You must remove the assembler from your unit.
> I know, that was only propositions, I make 3 procedures.
>> 2.  Your architecture is wrong. Don't descend from TFileStream.
>>    You should create a separate TStream descendent which takes    another 
>> stream as an argument in it's constructor, like the    compression streams 
>> or encoding streams.
> Why not descend. Why not exceed tFileStream, its natural. I want read text 
> file in the same way like binary file.

Because then you must also descend THandlestream, TPipeStream,
TIOStream, TDecompressionStream, TMemorystream, TDecodestream
etc etc etc.

Streams are more than just for files.

> While complicated, when it only 2 procedure should be added. Form me 
> tTextStream should be used to fast and simple read text file (or application 
> input stream) and no others, no allocate nor reallocate buffer. only simple 
> read (and write).

It's not so simple.

>> 3.  There is already a buffered stream (TBufStream, unit bufstream),    I 
>> suggest you enhance that.
> Sorry, i don;t know about it. Its simple to implemented it.
> But why it is in separated unit, nobody know about it (or to few). F.e. 
> Lazarus has own implementation of buffering.
> If we want to make faster programs, object like my should be in core unit, 
> then everybody use them, in other case every make own implementation.

Maybe, but then we should put all streams in Classes, and we're not going to
do that.


More information about the fpc-devel mailing list