On Mon, 22 Dec 2003 00:32:02 +0300, Konstantin Knizhnik
<[EMAIL PROTECTED]> wrote:
> I made all methods from persistent external functions. So now nstead
> of doing "obj/modify" you should use "modify obj". The name of all
> methods is preserved, except "load" method which is removed to
> "load-
Hello Robert,
I have released new version of DyBASE (0.16 ).
Graham Chiu implemented in Rebol program which used DyBASE to store
extracted mails from the server. It detects one problem in DyBASE related with
storing large
strings. That is why I have to release new version.
It also includes new
Robert M. Münch wrote:
> Hi, that's the difference in Rebol. It's not an OO language and it's
> object! datatype isn't OO related. Every word carries its own context.
> That's why you get the same words bound to different (new) contexts each
> time. The solution is to move the functions out of th
On Sat, 20 Dec 2003 21:16:01 +0300, Konstantin Knizhnik
<[EMAIL PROTECTED]> wrote:
> I thought, that once objet is created using prototype object, the
> values of prototype object fields are just copied to the new objects
> (doesn't matter whether them are scalars, series or functions).
> In thi
Hi Konstantin,
Am Samstag 20 Dezember 2003 19:16 schrieb Konstantin Knizhnik:
> Hello Gregg,
>
> Saturday, December 20, 2003, 8:02:18 PM, you wrote:
>
>
> GI> Hi Konstantin,
>
> GI> Thanks for your continued efforts! Thanks to your code, and Romano's
> GI> detective work, it seems a bug in CLEAR
Hello Gregg,
Saturday, December 20, 2003, 8:02:18 PM, you wrote:
GI> Hi Konstantin,
GI> Thanks for your continued efforts! Thanks to your code, and Romano's
GI> detective work, it seems a bug in CLEAR with hash! values may have
GI> been found, which is great!
GI> Also, some of us have talked
Hi Konstantin,
Thanks for your continued efforts! Thanks to your code, and Romano's
detective work, it seems a bug in CLEAR with hash! values may have
been found, which is great!
Also, some of us have talked about things a bit, and an expert opinion
is that REBOL's prototype object approach just
Hello Robert,
With the help of Rebol mail list members, I was able to significantly
improve performance of Rebol API. Now the difference with for example
Python, is not so high. I do not believe that it is possible to do
something more in improving performance. Certainly it is possible to
speed u
On Fri, 19 Dec 2003 01:45:05 +0300, Konstantin Knizhnik
<[EMAIL PROTECTED]> wrote:
> I improve my own "record".
> Looks like the best solution (not only for this example) is:
> ...
Hi, for this version I get:
Elapsed time for adding 20 records 0:00:01.452
--
Robert M. Münch
Management &
Result of latest DocKimbel version on my Dell laptop...
>> Elapsed time for adding 20 records 0:00:01.221
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, December 19, 2003 4:58 AM
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: Profiling Rebol
T> 125000 0:00:05.33
RPT> 15 0:00:06.98
RPT> 175000 0:00:09.06
RPT> 20 0:00:09.83
RPT> ---
RPT> Ciao
RPT> Romano
RPT> - Original Message -
RPT> From: "Romano Paolo Tenca" <[EMAIL PROTECTED]>
RPT> To: <[EMAIL PROTECTED]>
RPT> Se
10 0:00:03.96
125000 0:00:05.33
15 0:00:06.98
175000 0:00:09.06
20 0:00:09.83
---
Ciao
Romano
- Original Message -
From: "Romano Paolo Tenca" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 19, 2003 4:49 AM
Subject: [REBOL] Re: Prof
Hi Konstantin,
Here's a version executing 10 times faster. I just changed h series type from
hash! to list!. Looks like in your case, cost for adding data is much higher
than for searching keys...
Regards,
-DocKimbel
n: 20
h: make list! n
l: make block! n
start: now/time/precise
repeat i
Hi,
> I was able to isolate the problem.
> The following script shows almost the same time as testindex.r
> searching for 20 objects.
>
>
> n: 20
> h: make hash! n
> start: now/time/precise
> repeat i n [
> oid: random n
> obj: select h oid
> if none? obj [
>obj: make
I improve my own "record".
Looks like the best solution (not only for this example) is:
n: 20
h: make hash! 101
cache-size: 101
cache-used: 0
start: now/time/precise
repeat i n [
oid: random n
obj: select h oid
if none? obj [
obj: make object! [__oid__: oid]
if cac
Hello Gregg,
I was able to isolate the problem.
The following script shows almost the same time as testindex.r
searching for 20 objects.
n: 20
h: make hash! n
start: now/time/precise
repeat i n [
oid: random n
obj: select h oid
if none? obj [
obj: make object! [__oid
Hi Konstantin,
KK> So, during index search 1.5 minutes from 2 were spent in lookup
KK> function. And 14 seconds takes searching index itself.
KK> From these 1.5 minutes most of the time was spent in this line:
KK> obj: select obj-by-oid-map oid
A quick test seems to show that the SELECT pa
17 matches
Mail list logo
