On Sun, Oct 21, 2012 at 6:24 AM, hakan <hexi...@users.sourceforge.net>wrote:
> **
> Staffan
> Here is the results from my test run. 3 times for each type.
> Table 1 contains unique keys and table 2 contains records to these keys
> (one to many relation)
> Count is total items in each table.
> Timer is started just before database open and ends after database close.
> In the case for exec I do an iteration over the result from table 2, but
> do nothing.
>
> Using ~bindtext is faster than to create a total new query, looking the
> same except for the key (in table2), each time, as you can see.
>
> I also agree that exec is more convenience to use and that even if one
> can cut the time reading a sqltable, it doesn't matter,
> if the result is to be presented in a ooDialog tree or whatever, that's
> where the time is spent (at least in my case, showing the (exec) result in
> a ooDialog treeview, we talk minutes!)
>
> Anyway, I will later also try out your suggestion to use callback to
> construct my own directory objects when using step.
> I will take it step by step :-)
> /hex
>
> ---------------------------------------------------------
> - SQL exec -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed time 00:00:10.340000
> - SQL exec -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed time 00:00:10.071000
> - SQL exec -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed time 00:00:10.123000
> ----------------------------------------------------------
> - SQL step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:05.602000
> - SQL step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:05.971000
> - SQL step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:06.919000
> ---------------------------------------------------------
> - SQL Bind step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:02.450000
> - SQL Bind step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:02.460000
> - SQL Bind step -
> Table 1 items 27982
> Table 2 items 234988
> Elapsed Time 00:00:02.460000
> -------------------------------------------------------------
>
> I used this for the timer
>
> timer = .timer~new
>
> my testcode
>
> say timer~elapsed
>
>
> ::class timer
> ::method init
> self~reset
> ::method reset
> expose timestamp
> timestamp = .datetime~new
> ::method elapsed
> expose timestamp
> return .datetime~new - timestamp
>
Useful, but note that the DateTime class does have an elapsed method!
Rick
>
>
> ----- Ursprungligt Meddelande -----
> *Från:* Staffan Tylen <staffan.ty...@gmail.com> <staffan.ty...@gmail.com>
> *Till:* <hexi...@users.sourceforge.net> <hexi...@users.sourceforge.net> ,
> Open Object Rexx Users
> <oorexx-users@lists.sourceforge.net><oorexx-users@lists.sourceforge.net>
> *Kopia:*
> *Datum:* lördag, 20 oktober 2012 22:13
> *Ämne:* Re: [Oorexx-users] oosqlite ? step and result
>
> **
>>
>> I have tried sql statements with :aname or ?1 or etc and then bind a
>> value to that parameter with ~bindtext as I think I get a performance gain
>> by doing so, part of the sql is already "compiled" by sqlite and it would
>> be conveniant to get the result back as directory object for each step.
>> As I followed the conversation about "performance observation..." I
>> realized that creating the directory objects with (~exec) current
>> implementation take some resources, I have tables with ~300 000 rows and
>> ~10 columns, and wants to have the convineance of using the directory
>> objects as reference to the returned row together with the ~bindtext
>> possibility, less changes to some existing code I have :-).
>> /hex
>>
>> OK, I see what you mean. My immediate reaction is - because Rexx is an
> interpretive language, even if compiled, there is the possibility that
> there is very little to gain from using SQL bind. I believe the effort for
> SQLite to compile an SQL statement is almost negligible compared to Rexx
> compiling and executing a Rexx statement. I started to look into the
> possibility of using bind but found that I had nothing to gain, it just
> complicated my coding. As I've stated earlier, by using exec all the major
> processing is done in compiled code in contrast to step, where Rexx must be
> called for each row. I can imagine that handling 300,000 rows in Rexx will
> have an impact on performance.
>
> In any case it would be very interesting if you had a chance to make a
> performance comparison between the two. For this you would need to
> establish the input and the exact format of the output, then build the step
> and exec routines that when executed will take you from A to B. Then use
> the time("E") function to time each of them.
>
> Also remember that when you use exec you also have the callBack
> functionality available where you can handle individual rows just like step
> to build for example a directory. If I remember correctly, in the callBack
> routine you also have the power to terminate a query before you have
> processed all rows, just like step.
>
> Staffan
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Oorexx-users mailing list
> Oorexx-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-users
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
