"filia&sofia" <in_tyrannos@hotmail.com> writes:

>> Since when did compression come into it?
>
> It didn't.
>
>> You are providing no information. "Fast" is a relative thing. If you
>> have ideas about "fast" then you must have ideas about what isn't fast.
>
> It seems that everyone here needs strict conditions to be able to say
> anything. "Fast" is relative thing. "Compression" was an analogy.

Compressions was nothing to do with it. Are you seriously trying to
explain your use of "fast" by mentioning that compressions may be or
may not be fast depending on the algorithm?

>
>> "Run fast" is something just about every program should aim to do - not
>> thinking about that has led to the incredible bloatware which infests
>> platforms today and ensures that PCs which are 1000 times faster than 20
>> years ago open a Word Processor in the same time as opposed to in a
>> blink of an eye.
>
> And this is relevant?

Yes.

>
>> Most C programmers use C because they have an eye on efficiency in terms
>> of CPU and memory usage IMO.
>
> Perhaps.

And still you do nothing to provide information needed to answer your
question other than your pie in the sky "it must be fast".

I was trying to say that this isn't specific enough because "fast"
should be an aim for most program IMO. And "fast" can be specified in
many ways -fast to start up, fast to read a file, total time, use lest
system or cache memory etc etc etc.

It seems to me you're just looking for someone to write your program. I
hope someone does for you, but until then why not post your attempt and
then other people can comment on structure and choice of algorithms to
hopefully optimise it yet further.