Marco van de Voort wrote:
I found a png, but can't seem to find the original file (it is in .dia
format), will have to search for it.
http://www.stack.nl/~marcov/decalhier.png
If you can't find the eps - or never had any - I can create one on my own
(using xfig).
Anyway, here is a patch for
> >
> Ouch, it bites, ehmmm or should I say it bytes ;) Very interesting
> stuff, but not for mere mortals like me :)
> Really out of my reach. I'll try to play with it, just to try to see how
> it works (even if I doubt I'll be able to understand the compiler god's
> code :)
Mere RTL god ;)
Marco van de Voort wrote:
>Better finish decal. DeCal is good and comfortable for most cases, and
>trying to speed it up will kill the ease of use.
>
>Then we can collect some other set of routines over time for more performance
>dependant stuff.
>
>
You are right, it will be probably the easier
Michael Van Canneyt wrote:
> What is the performance difference between a hash() and a binary search on
> an ordered list ?
IMO perfomance heavily depends on the use of the lists. An ordered list
requires some efforts when entering or removing items, and typically
requires more comparisons than a
> Marco van de Voort wrote:
> > I have a tex version of the decal docs somewhere.
> >
> > http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files)
> >
> > compiled to
> >
> > http://www.stack.nl/~marcov/decal.pdf
>
> I am reading this manual now, because I want to familiarize
Marco van de Voort wrote:
I have a tex version of the decal docs somewhere.
http://www.stack.nl/~marcov/decal.tex (might use some FPC tex docs files)
compiled to
http://www.stack.nl/~marcov/decal.pdf
I am reading this manual now, because I want to familiarize myself with this
lib. Meanwhil
> >At work, I have found out that decal is too bulky and too slow for some
> >purposes (I've lists with millions of objects in memory). _each_ entry in
> >a decal container eats 78 byte (with D6 memory manager, but will only be
> >equal or larger with FPC)
> >
> I can immagine, the DObject is a TV
Bram Kuijvenhoven wrote:
> Besides using TVarRecs, we could also use pointers (as in
> classes.TList) or objects.
Pointers like in TList were the things I had in mind.
> This would perhaps be a bit like it is in java.util. Then we would
> also need container classes for basic types such as bool
Marco van de Voort wrote:
>>Dean Zobec wrote:
>>
>>
>>>As the project looks like a long term one and I think that fpc urgently
>>>needs a optimized hash table I'll also work on a streamlined hash table
>>>with a chaining technique as a collision resolution scheme and a paging
>>>for the alloc
Dean Zobec wrote:
I can immagine, the DObject is a TVarRec. The problem with speed and
memory usage are the things that I don't like in Decal and it still
makes me wonder if it would be better to reimplement a containers
library from scratch, if we had generics to add type checking at compile
t
Marco van de Voort wrote:
>>The generic functions are very powerful and model closely the C++ STL
>>library (as fpc does not have generics yet a sort of typecast is still
>>required when fetching the items from the container). The library was
>>not designed for speed though, from the first test th
> > Depends how the hash is parametrized. If you've a big hash array and a
> > good hash function accessing has a complexity of O(1) while for a binary
> > search it's O(log(n))
>
> But I assume that calculating the hash becomes harder for 'better' hashes ?
Only for general purpose hashes. Specif
Michael Van Canneyt wrote:
>What is the performance difference between a hash() and a binary search on
>an ordered list ? I've also been working with an 'associative' stringlist, but
>I was using an ordered stringlist to keep the data, so a binary search is done.
>
>
The TStringList is a very f
Michael Van Canneyt wrote:
>>Depends how the hash is parametrized. If you've a big hash array and a
>>good hash function accessing has a complexity of O(1) while for a binary
>>search it's O(log(n))
>>
>>
>
>But I assume that calculating the hash becomes harder for 'better' hashes ?
>
Not alwa
On Tue, 21 Jun 2005 21:42:19 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Depends how the hash is parametrized. If you've a big hash array and a
> > good hash function accessing has a complexity of O(1)
> > while for a binary
> > search it's O(log(n))
>
> This is no fair compari
> > I would make that the contnrs unit. I think it belongs more together with
> > objects such as a stack and queue...
> >
> > What is the performance difference between a hash() and a binary search on
> > an ordered list ? I've also been working with an 'associative' stringlist,
> > but
> > I
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
> Michael Van Canneyt wrote:
>
> >
> > On Tue, 21 Jun 2005, Florian Klaempfl wrote:
> >
> >
> >>Dean Zobec wrote:
> >>
> >>>As the project looks like a long term one and I think that fpc urgently
> >>>needs a optimized hash table I'll also work o
Michael Van Canneyt wrote:
>
> On Tue, 21 Jun 2005, Florian Klaempfl wrote:
>
>
>>Dean Zobec wrote:
>>
>>>As the project looks like a long term one and I think that fpc urgently
>>>needs a optimized hash table I'll also work on a streamlined hash table
>>>with a chaining technique as a collisi
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
> Dean Zobec wrote:
> > As the project looks like a long term one and I think that fpc urgently
> > needs a optimized hash table I'll also work on a streamlined hash table
> > with a chaining technique as a collision resolution scheme and a paging
>
> Dean Zobec wrote:
> > As the project looks like a long term one and I think that fpc urgently
> > needs a optimized hash table I'll also work on a streamlined hash table
> > with a chaining technique as a collision resolution scheme and a paging
> > for the allocation of the nodes in the chains,
> The generic functions are very powerful and model closely the C++ STL
> library (as fpc does not have generics yet a sort of typecast is still
> required when fetching the items from the container). The library was
> not designed for speed though, from the first test the DArray class is
> twice a
Dean Zobec wrote:
> As the project looks like a long term one and I think that fpc urgently
> needs a optimized hash table I'll also work on a streamlined hash table
> with a chaining technique as a collision resolution scheme and a paging
> for the allocation of the nodes in the chains, to have a
John Briggs wrote:
>This is a repost of an earlier response to another thread. I did not recieve
>any response so I am posting this in its own thread.
>
>I have several old books (circa 1991), including source code, covering TP6 in
>my library.
>
>
I still remember the Algorithms + Data Structu
On Tue, 21 Jun 2005, John Briggs wrote:
This is a repost of an earlier response to another thread. I did not recieve
any response so I am posting this in its own thread.
I have several old books (circa 1991), including source code, covering TP6 in
my library.
Perhaps the most interesting one
24 matches
Mail list logo
