On Tue, 10 Jan 2017 13:52:05 +1300, Gordon Findlay via Lazarus
wrote:
>I've had that issue, with different units, under Linux several times. A
>make clean before make bigide has solved the problem.
>
Well, in my case there was nothing to clean out since the source
I've had that issue, with different units, under Linux several times. A
make clean before make bigide has solved the problem.
YMMV of course.
On 10/01/2017 12:48 pm, "Bo Berglund via Lazarus" <
lazarus@lists.lazarus-ide.org> wrote:
I am trying to build an FPC 3.0.0 + Lazarus 1.6.2 environment
On 1/10/17, Werner Pamler via Lazarus wrote:
> Ah - that's the explanation: you did your test with a predimensioned
> table? Mine started with an empty table, and with every new cell the
> tree sorts the new cell to the correct location and rebalances itself.
> It
An empty cell occupies only a nil pointer.
It may sum up, though, if the table is large and sparsely populated.
Mind you that when you do not know the dimensions of the table AND you
have to increase ColCount several times whilst filling the table, then
I suspect things will slow down
I am trying to build an FPC 3.0.0 + Lazarus 1.6.2 environment on a new
Rpi3 with the latest Raspbian PIXEL.
I have come so far as to having compiled fpc 3.0.0 successfully and
run its make install command to put the binaries in the expected
places (all under /home/pi):
Now when I try to build
On 1/9/17, Werner Pamler via Lazarus wrote:
> I would be tempted to implement such a table in fpspreadsheet, but its
> problem is that it occupies memory for empty cells
An empty cell occupies only a nil pointer.
Mind you that when you do not know the dimensions
Amazing. I tried the AVLTree used by fpspreadsheet and it needs 0.37 sec
for 1000x1000 and 10.3 sec for 5000x5000.
My tests were all "in memory", no disk access whatsoever.
Bart
Mine as well.
I would be tempted to implement such a table in fpspreadsheet, but its
problem is that it
On 1/9/17, Werner Pamler via Lazarus wrote:
> Amazing. I tried the AVLTree used by fpspreadsheet and it needs 0.37 sec
> for 1000x1000 and 10.3 sec for 5000x5000.
My tests were all "in memory", no disk access whatsoever.
Bart
--
On 1/9/17, Lukasz Sokol via Lazarus wrote:
> For such usage, it is rather assumed that NO substring can contain EOL of
> any kind,
For the intende purpose of TStringTable, this is certainly NOT the case.
> EOL is assumed to be meaning end of a string here. Not
Am 2017-01-09 um 16:28 schrieb Werner Pamler via Lazarus:
Am 05.01.2017 um 16:35 schrieb Bart via Lazarus:
filling a 1000x1000 TStringTable just cost me 76 ms.
A 5000x5000 table however cost me 1248 ms.
Amazing. I tried the AVLTree used by fpspreadsheet and it needs 0.37 sec for
1000x1000
Am 05.01.2017 um 16:35 schrieb Bart via Lazarus:
filling a 1000x1000 TStringTable just cost me 76 ms.
A 5000x5000 table however cost me 1248 ms.
Amazing. I tried the AVLTree used by fpspreadsheet and it needs 0.37 sec
for 1000x1000 and 10.3 sec for 5000x5000.
--
On 07/01/17 21:49, Bart via Lazarus wrote:
> I think my current implementation is cleaner.
> As long as you do not plan on having a table > 1000x1000 it behaves
> quite nicely IMO.
>
Right now i think, there is a shortage of standard non-visual classes that can
handle
first 2 degrees of
12 matches
Mail list logo