You are doing disk block reads in the one case which is why it is slower, how big is your global buffer pool? Also how big are your globals ^TestD and ^TEST2, use 'd ^%GSIZE' to find their sizes on disk. The $lb version will be slightly bigger as there is a byte taken as a type byte for each element and another length byte, this shows up when the data is very small like these single character ASCII elements, but $lb does mean you never need to worry about data that contains '#' characters and it preserves types where as the "a#b#..." format needs to convert everything into a string before storing it which adds runtime overhead too.

-- 

Mark

Either will work, but referencing the 'Name' property is a lot faster.

A few comments:

  • %ResultSet does have %Execute, %Next, %GetData, %Get, %Prepare methods also
  • In %ResultSet use 'Data' multidimentional property to get columns by name as this is more efficient than the 'Get' method.
  • In %SQL.StatementResult, do not use %Get to get columns by name, instead just reference the properties directly, e.g. 'Write resultOref.Name' instead of 'Write resultOref.%Get("Name")'

I think you have a typo and you meant to write:

And also you should remember that you can NOT store objects in globals, even if it is Process-private one.

The biggest issue I saw is that when you call %Save() you are returning the Status code into variable 'Status' which is good, but then this variable is totally ignored. So if you save an object which does not for example pass datatype validation the %Save will return an error in the Status variable but the caller will never know the save failed or why the save failed.

In addition %DeleteId does not return an oref, it returns a %Status code, so you need to check this to see if it is reporting an error and report this to the caller if it does also.

 

Correct, the gateway will not cached files that are not served from 'always and cached'. Of course if you served a static file when this was set and then unset this then the gateway will still have it in its cache. Also the timeout value applies both to the browser timeout period and the CSP gateway timeout period.

You can also remove items from the gateway cache using code (which we do automatically when you edit a static file in Studio):

Set registry = $System.CSP.GetGatewayRegistry()

Set sc=registry.RemoveFilesFromCaches(remove)

See the class %CSP.Mgr.GatewayRegistry for more details of this method.

You are basically correct. We do try to minimize branch points in the tree, so an array with one subscript array("very long subscript") only has a single element in it rather than one per byte associated with the subscript. So this reduces it to <k depending on the distribution of the keys. 

In memory arrays use a ptrie format and are also O(ln n) lookup time.

Awesome, that is great news. Thanks for making this tool.

I think scrolling and showing the output as soon as possible is the most useful as this shows the user what is happening and it is the same behavior for all other terminals I have used. Often you can make out patterns in the output even though it is scrolling and this can be handy.

The other thing I noticed is that Ctrl+C does not appear to work, is it meant to?