[jawsscripts] Re: Resizing arrays
- From: Doug Lee <doug.lee@xxxxxxxxxxxxxxxx>
- To: jawsscripts@xxxxxxxxxxxxx
- Date: Thu, 5 Jan 2012 16:07:59 -0500
I generally use the collection-array approach when growth is likely to
be as regular as access, or when the upper bound on array size is
unclear enough to make coding with arrays complicated. I use arrays,
even if a bit oversized, when neither of these is true. For whatever
reason though, most of the time I find one or the other of those
conditions is met by my projects.
I actually wonder which is ultimately more efficient with memory use.
I do a lot of scripting for chat-like interfaces, and I need
arrays/collections for the more complex of them... so if one can
assume a new line will be added often, I wonder if it's better overall
to use a collection or to expand an array by, say, 50 lines at a time.
Element accesses will usually be at user request and therefore limited
more by typing speed than by order of computational complexity.
On Thu, Jan 05, 2012 at 05:59:57PM -0300, Andrew Hart wrote:
Travis,
Ah, ok. Well, it is usually the case you don't know what the final size
of an array is. Resizing is a pretty common operation. The question is
how often you need to do it and how important is speed.
For arrays: resizing takes linear time and accesses take constant time.
For collections, resizing is dynamic and takes constant time (so far as
i know) while accesses are also constant time operations. However
accesses to collections require computing a hash function to fetch the
pointer to the item you wish to access. The hash function computation
is more complex than the very low-level offset calculation needed to
access an array.
However, I imagine for JAWS, the access time difference probably isn't
significant enough to be a major concern, except in some incredibly
extreme applications.
So, as Doug has pointed out, collections with string-encoded numeric
keys is probably the way to go for you.
As for memory management and properly cleaning up arrays when you
reassign to them, I certainly hope FS have crossed there t's and dotted
their i's. Given the memory leak issues FS have experienced in the
past, it would surprise me if they didn't do their due diligence on this.
We can always make a test to assign bigger and bigger arrays (say a few
thousand times) and see if JAWS chews up all the memory in the machine.
Anyone game to try it out? *smile*
Cheers,
Andrew.
On 5/01/2012 5:20 PM, Travis Roth wrote:
> Yes I thought the array copy was by reference as well.
>
> I have the same problem of not knowing array size in advance.
> But it does look useful that you can just make a new array on the existing
> variable, I hadn't realized that was possible. Does the old array just stop
> existing when new is called again? We've lost access to it but I am just
> wondering if JAWS does any garbage collection. I am thinking in the case of
> the default scripts, where those global variables are in existence until
> JAWS is unloaded, if garbage collection does not automatically occur using
> new repeatedly would start to be a memory leak.
>
> Like the ideas... Thanks everyone.
>
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee
> Sent: Thursday, January 05, 2012 1:55 PM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: Resizing arrays
>
> A couple clarifications:
>
> First, to me at least, a "deep copy" is a full duplication of something with
> all subparts. My understanding of "s2 = s1" where they are arrays is that,
> in JAWS, only the pointer is copied. It still works for your usage though,
> so this is mostly just behind-the-scenes stuff for this case.
>
> Second though, your code assumes array sizes, and most of my cases don't
> have a clue in advance what size to use. As an example, consider code that
> creates a structure of information for each entry in a chat window. If the
> process of counting entries is as expensive as that for actually retrieving
> them, there's no reasonable way to know in advance how big to make the
> array. A collection becomes more efficient in this case, because it is
> dynamic while still being amenable to random access.
>
> On Thu, Jan 05, 2012 at 03:59:00PM -0300, Andrew Hart wrote:
> I don't understand your need for collections in order to use arrays
> globally. You just create the array at the size you need. If you need to
> add to it, you just fob it off to a local variable, assign a new larger
> array to the global var and then copy the array elements in the local var to
> the global one. Then, to finish, you erase the copy of the array by
> assigning it an unassigned array var of the same type, much as you would do
> with Object vars.
>
> For example:
>
> Var
> StringArray s1,
> StringArray S2,
> StringArray NULLStringArray
> s1 = New StringArray[5]
> ; fill the array with stuff
> ...
> ;Copy the array (this is a deep copy, not a shallow copy that only ;passes a
> reference pointer)
> s2 = s1
> s1 = New StringArray[10] ; make the array bigger ; Now copy the contents of
> s2 to s1 For i = 1 To 5
> s1[i] = s2[i]
> EndFor
> ; erase the array.
> ; Since JAWS performs deep array copies, it should reduce s2 to its ;minimal
> memory footprint, allowing the space to be reclaimed by the ;heap when
> appropriate conditions prevail
> s2 = NULLStringArray
>
>
> If you're serious about regularly resizing arrays, I'd recommend making a
> few functions using the relevant bits of the above example for resizing
> arrays of different types. You'd pass the array being resized by reference
> (using ByRef in the function declaration). Also, as this is a linear time
> operation, doing it a lot could slow things down if you are dealing with big
> arrays. Tricks for dealing with that are to always make the array bigger
> than what you need. For example, you could always double the size of the
> array whenever you run out of space and then resize it to conserve memory by
> removing unused portions later if it is not likely to be added to for a
> while.
>
> Hth,
> Andrew.
>
> On 5/01/2012 2:32 PM, Travis Roth wrote:
>> Perhaps a combination of a collection and an array would work then?
>> The documentation states that a collection can hold arrays. So when a
>> new array is wanted, delete the old one in the collection and make a new
> one.
>>
>> I am not sure what type of performance that'd give, but might be
>> another workaround.
>>
>> The reason for not just creating new arrays is I need them to be
>> global, and there'd be no way to keep track of the names, or at least
>> not a practical way.
>> Bbut a collection may solve that.
>>
>> -----Original Message-----
>> From: jawsscripts-bounce@xxxxxxxxxxxxx
>> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee
>> Sent: Thursday, January 05, 2012 11:26 AM
>> To: jawsscripts@xxxxxxxxxxxxx
>> Subject: [jawsscripts] Re: Resizing arrays
>>
>> JAWS 12 introduced a CollectionRemoveItem function for that.
>>
>> On Thu, Jan 05, 2012 at 11:23:32AM -0600, Travis Roth wrote:
>> Kind of messy but I see your reasoning.
>> How do you remove an item from a collection?
>>
>>
>> -----Original Message-----
>> From: jawsscripts-bounce@xxxxxxxxxxxxx
>> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee
>> Sent: Thursday, January 05, 2012 10:21 AM
>> To: jawsscripts@xxxxxxxxxxxxx
>> Subject: [jawsscripts] Re: Resizing arrays
>>
>> In the absence of knowledge of a way to do that, I've been using
>> collections as dynamic arrays, where the keys are things like
>> intToString(i). You do need to stringify the keys though. When I do
>> that, I also sometimes include a count key that I keep updated when
>> adding or removing elements. This also allows for efficient sparse
>> arrays but does complicate their management a bit and precludes things
>> like inserts/deletes where elements slide in to fill the hole or make
> room.
>>
>> On Thu, Jan 05, 2012 at 10:17:13AM -0600, Travis Roth wrote:
>> Is it possible to resize arrays in JAWS script?
>> It appears that the arrays are dynamically sized at runtime because
>> the new keyword is used.
>> But the documentation on the website does not seem to discuss
>> destroying or resizing arrays?
>> This may not be an issue for local variables, but I am thinking for a
>> global array where at some point it may be desireable to store
>> something larger than was originally set for.
>>
>>
>>
>> __________???
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>> --
>> Doug Lee, Senior Accessibility Programmer SSB BART Group -
>> Accessibility-on-Demand mailto:doug.lee@xxxxxxxxxxxxxxxx
>> http://www.ssbbartgroup.com "While they were saying among themselves
>> it cannot be done, it was done." --Helen Keller __________o?=
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>>
>> __________???
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>> --
>> Doug Lee, Senior Accessibility Programmer SSB BART Group -
>> Accessibility-on-Demand mailto:doug.lee@xxxxxxxxxxxxxxxx
>> http://www.ssbbartgroup.com "While they were saying among themselves
>> it cannot be done, it was done." --Helen Keller __________o?=
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>>
>> __________???
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>>
>>
>
>
> __________???
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
> --
> Doug Lee, Senior Accessibility Programmer SSB BART Group -
> Accessibility-on-Demand mailto:doug.lee@xxxxxxxxxxxxxxxx
> http://www.ssbbartgroup.com "While they were saying among themselves it
> cannot be done, it was done." --Helen Keller __________o?=
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
> __________???
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
>
__________???
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug.lee@xxxxxxxxxxxxxxxx http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Other related posts:
