• Welcome to Theos PowerBasic Museum 2017.

Hi Speed Datacollections for PB 10

Started by Theo Gottwald, August 11, 2011, 06:40:35 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Theo Gottwald

A special recommendation are Stan Durhams Hi-Speed Datatypes.
They beat the builtin "PowerCollection","PowerQue" etc. in terms of speed because they are not using VARIANTS but declared Datatypes.
Very useful and recommended when Speed is what counts.

Stan's Datatypes

I'd wish these would all be builtin directly in PowerBasic.
While they are not i can use these SLL's and just include them.

Edwin Knoppert

I ever wrote me a dictionary using sqlite (memory table)
I wonder what the bottleneck can be, the filling process or the usage (lookup and such).
Can you elaborate what would be a speed issue?

I solved the filling speed using a select into which populates via sqlite itself.
The object storage doesn't have to be an issue, it's merely a pointer and a reference call, it stores no bytes besides the variant itself.

Theo Gottwald

#2
It depends on what you are really doing. For example a Flood-Fill Algo?
You need a very fast stack to hold potentially Millions of Pixel coordinates.

For many other things the built in PB "VARIANT-Versions" are fast enough.

Having said that, the speed difference in my tests was significant using Stan's datatypes.
I assume the difference come from the usage of Pointers, while the original (universal) versions use VARIANTS.

Edwin Knoppert

>You need a very fast stack to hold potentially Millions of Pixel coordinates.
I wonder if this example should be done with a dictionary?
The D. is keyname based and the KN is used to locate an item.
Your example sounds like an array but i may be wrong.
I am not debating what you are doing, i am looking for the criteria to use it and the speed of it.
I mentioned the loading and using (like searching a member by keyname) to determine what's more important for someone.
Having speed in both areas may be a problem, therefore.

A B-tree engine may be enough for many situations but storing objects (in a variant) is highly friendly as development.
In .NET we do nothing else and there is a dictionary even more supurb, it's truly fast but also dynamic to setup.
It can be a <list> but can also be as you want it like having several string values (+ the key field).
This flexibility helps development very and speed may come second.., anyway there are no real speed issues for D. in .NET so far, i did a test.
I think it's good that PB introduced their version of it, once you get used to it you will use it often.

Theo Gottwald

#4
@Edwin: I was talking from the QUE and the STACK.

As said, under normal programmer circumstances the PB builtin is good enough.
If you work - for example - on graphical stuff, having to remember a lot of (100.000 and more) Pixel coordinates,
and you want things to happen in real time, this may not work.

Stans Datatypes are extraordinary fast and easy to use.
I wish they had been builtin.

QuoteI think it's good that PB introduced their version of it, once you get used to it you will use it often.

While I agree to the first part of your sentence, i can't pay the price (in CPU Cycles) for the comfort of these builin Objects.
I'll use Stan's Datatypes instead.

I must however admit that i am not coming from the VB side of life and avoid using VARIANTS and conversions where i can.
For Speed Reasons.