On Sun, Oct 21, 2012 at 7:27 AM, Staffan Tylen <staffan.ty...@gmail.com>wrote:
> Hmm, that's interesting Håkan. I think I may have to revisit step and
> bind, I've obviously have drawn the wrong conclusions. Thanks for this.
>
One thing you've overlooked in your conclusions is the effect of keeping
large numbers of "live" objects in memory has on the garbage collector.
The processing of an individual item might be faster, but as the size of
the active memory heap grows, each garbage collection cycle takes longer
because there are more live objects that need to be traced. Add in the
paging effects from having a larger working set, and I'm not particularly
surprised that step benchmarks as faster. If you don't really need to have
all of the data in memory at one time, you are better off not retrieving
everything at one time.
Rick
>
> As for the treeview, to cope with response times I've implemented an
> 'onExpand' method so that data is only populated when then user asks for it
> and it works great. In addition I've created a context menu containing an
> 'Expand All' option that expands and populates data from that point to a
> certain (user-defined) depth. It also works fine but can create long
> response times depending on the data being expanded. If the SELECT
> statement only specifies the column that I want to show in the treeview, I
> haven't had any performance problems at all, but again this may boil down
> to the hardware one is using....
>
> Staffan
>
>
> On Sun, Oct 21, 2012 at 12:24 PM, 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
>>
>>
>> ----- 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
>
>
------------------------------------------------------------------------------
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
