Showing posts with label manipulation. Show all posts
Showing posts with label manipulation. Show all posts

Saturday, 16 June 2012

Undocumented feature - interrupt - part eight


Continuing from part seven where we looked at "989", I will now do a full summary of the known functionality that we've looked at in this series of posts...


Code Description Example Alternative
0File information
interrupt(0,"test.txt")
if ( $status < 0 )
  ;file doesn't exist
else
  list = $result
  name = $item("Name",list) ;"test"
  type = $item("Type",list) ;"txt"
  vers = $item("Version",list) ;""
  attr = $item("Attrib",list) ;"UUU"
endif
This doesn't seem to return any useful information now.


Could use:
$fileproperties or
$lfileproperties


These return lots more file information, but not the same.
2Extract filenameinterrupt(2,"C:\temp\test.txt")
filename = $result ;"test.txt"
Use string manipulation
(although interrupt takes 60% of the time)
3Extract file pathinterrupt(3,"C:\temp\test.txt")
filename = $result ;"C:\temp\"
Use string manipulation
(although interrupt takes 60% of the time)
5Working directoryinterrupt(5,"")
working = $result ;"C:\temp\"
Use:
$ldir
5Uniface "usys" directoryinterrupt(5,"USYS")
uniface = $result ;"C:\uniface\"
Use:
$fileproperties of "usys:"
6Concatenate file path$result "C:\temp"
interrupt(6,"test")
filepath = $result ;"C:\temp\test\"
Use string manipulation
(although interrupt takes 70% of the time)
7Parent directoryinterrupt(7,"C:\temp\test\")
parent = $result ;"C:\temp\"
Use string manipulation
(although interrupt takes 33% of the time)
10Directory listing (files)interrupt(10,"C:\temp")
list = $result ;"test.txt·;test2.txt"
count = $status ;2
Use:
$dirlist or
$ldirlist (with "FILE" topic)
11Directory listing (folders)interrupt(11,"C:\temp")
list = $result ;"test·;test2"
count = $status ;2
Use:
$dirlist or
$ldirlist (with "DIR" topic)
989Application focusinterrupt(989,"APPLFOCUS") No alternative
(doesn't seem to work anyway)
989Format string
$result "RPL"
interrupt(989,"FORMAT")
string = $result
Use string manipulation
(doesn't seem to work anyway)
989Undo gold characters$result "R·;P·!L"
interrupt(989,"UNDOGOLD")
string = $result ;"R;P!L"
Use:
$replace



It seems that the interrupt command isn't really very useful anymore.  The functionality has either been replaced by new Uniface functions, or can be achieved by string manipulation.  Given the performance improvements, it may be worth considering using interrupt if you are heavily handling file paths, but given the number of iterations needed to see the difference, I'd be surprised if this was ever worthwhile.


Given the numeric nature of the code, I'm sure that the unknowns (1, 4, 8 and 9) must do something too - I'd love to know what!  Probably some of 12-988 do something as well, so I'm sure there are some hidden gems within the interrupt command.  If you know of any, please let me know in the comments.

Undocumented feature - interrupt - part seven


Continuing from part six where we looked at "10", "11" and "12" onwards, we're now going to look at "989".  This has a number of different uses, which are used by the debugger, so should be relatively safe to use moving forwards.


989 - Application focus


When the debugger kicks in, maybe caused by a debug statement in your code, the focus is immediately set to the debugger.  Apparently this is done using the interrupt command...


interrupt(989,"APPLFOCUS")


As far as I can tell this doesn't work, maybe because I'm using Windows 7 for my testing.  When you hit a debug statement it does bring the debugger into focus, but if my Uniface application calls the interrupt command above whilst another application has focus, it does not come into focus as I would expect.





989 - Format string


According to PUUU, this is supposed to format a string by adding carriage returns in.  It's not clear on the details, but something like this...


$result "RPL"
interrupt(989,"FORMAT")
string = $result


However, I couldn't get this to work for me, $result remained unaffected.  If you wanted to do something like this then you could use string manipulation, but I'm not sure why you'd want to.  Again, this is supposed to be used by the debugger, but I can't recall seeing an behaviour like this myself.





989 - Undo gold


When the debugger displays lists, it always uses semi-colon (;) and exclamation mark (!) as the delimiter, instead of their gold equivalents.  Apparently it uses the following command to do it...



$result "R·;P·!L"
interrupt(989,"UNDOGOLD")
string = $result

This replaces the gold delimiters with their normal equivalents.  It does not replace the wildcard characters, only the delimiters.  This one does actually work!  It's easy to find an alternative using $replace however...

string = $replace($replace("R·;P·!L",1,"·;",";",-1),1,"·!","!",-1)

This code is probably slightly easier to read, as you can easily see which characters are included in the "undo".  How about the performance though, over 2,000,000 iterations...

  • interrupt = 00:07.89, 00:07.64, 00:07.73 (almost 8 seconds)
  • $replace = 00:07.95, 00:07.83, 00:07.88 (almost 8 seconds)
So as you can see, it takes pretty much exactly the same amount of time either way, so I'll definitely be sticking with the alternative, instead of using interrupt.

Summary: Numeric code "989" has multiple uses, but it seems that they either don't work any more, or are easily replaced with alternatives.  I'll do a full summary of the interrupt command in the next post.




Friday, 15 June 2012

Undocumented feature - interrupt - part five


Continuing from part four where we looked at "4", "5" and "6"...


7 - Parent directory


This sets $result to be the parent directory of the file path that you specify, like this...


  interrupt(7,"C:\temp\test\")
  parent = $result



In this case $result would be set to "C:\temp\".  You could do this with string manipulation, but you need to be careful that you check to see if the last character is a delimiter or not...

  filepath = "C:\temp\test\"
  if ( $scan(filepath,"/") < 1 ) ;calculate delimiter
    del = "\"
  else
    del = "/"
  endif
  pos = $length(filepath)
  if ( filepath[pos] = del ) ;remove last character if delimiter
    filepath = filepath[1:pos-1] 
  endif
  pos = $rscan(filepath,del) ;find last delimiter
  filepath = filepath[1,pos] ;truncate string

As you can see, this isn't very concise either, and uses $rscan as well as $scan, so it's not likely to perform very well.  As with "6", I'll test with and without the code which calculates the delimiter, over 2,000,000 iterations...

  • interrupt = 00:05.16, 00:05.20, 00:05.09 (just over 5 seconds)
  • alternative = 00:17.74, 00:17.52, 00:17.67 (over 17 seconds)
  • without $scan = 00:15.62, 00:15.39, 00:15.41 (over 15 seconds)

Looking at these times, I'm struggling to argue for using the alternative!  I'm thinking I must be doing something wrong, so I'm going to try and refactor my alternative, without $rscan.  

I've just tried using $replace to convert the file path into a list, remove the last item (or two) and then convert it back again - this took slightly longer!  I'm going to have to give up with this for now, but I hope to tackle this again.


8 - Unknown


I haven't found any indication of what functionality this might be, but it does behave differently to "1" and "4", which are also unknown.  In this case it always returns a $status of 0 and $result is set to the string that you pass in.  I've tried all sorts of weird and wonderful things without getting anywhere, I'm giving up on this one for now too.



9 - Unknown


I haven't found any indication of what functionality this might be either.  This also behaves differently, as it always returns a $status of 0 but $result remains unaffected. 


Summary: Numeric code "7" could be very useful for finding the parent directory quickly, but "8" and "9" remain unknown.



Wednesday, 13 June 2012

Undocumented feature - interrupt - part four


Continuing from part three where we looked at "2" and "3"...


4 - Unknown


I haven't found any indication of what functionality this might be, but it does behave differently to "1", which was also unknown.  In this case it always returns a $status of 0 and $result is a blank string.  I tried folders, subfolders, filenames and a blank string, with no difference in behaviour.  I'm giving up, for now.



5 - Working directory


As discussed in part one, using numeric code "5" returns the working directory...

  interrupt(5,"")
  working = $result

The alternative is to use $ldir...

  working = $ldir()

The alternative is more maintainable, safer and also performs better.


6 - Concatenate file path

This takes the file path which is currently in $result and then concatenates the path you pass in, automatically adding the folder delimiters where necessary.  Here's some example code...


  filepath = "C:\temp"
  $result filepath
  interrupt(6,"test")
  filepath = $result



This will then populate $result with "C:\temp\test\".  As you can see, I had excluded the delimiter from the end of both the original $result value and the value I passed it, but the interrupt command fixed that.  Again, this is another string manipulation example, I came up with something like this...



  filepath = "C:\temp" 
  if ( $scan(filepath,"/") < 1 ) ;calculate delimiter
    del = "\"
  else
    del = "/"
  endif
  pos = $length(filepath)
  if ( filepath[pos] != del ) ;check filepath ends with delimiter
    filepath = "%%filepath%%del%%%"
  endif
  filepath = "%%filepath%%%test%%del%%%" ;concatenate filepath



As you can see, this isn't very concise, primarily because I'm accounting for Windows and Unix environments again, meaning that I have to first calculate the "del" local variable.  You could of course use $concat instead of using substitution, like I have.


I tested these two methods over 2,000,000 iterations with the following results...

  • interrupt = 00:06.67, 00:06.75, 00:06.72 (almost 7 seconds)
  • alternative = 00:12.02, 00:12.00, 00:12.04 (about 12 seconds)
  • without $scan = 00:09.04, 00:09.78, 00:09.74 (almost 10 seconds)

I added a third option which was the alternative but with a hardcoded delimiter instead of calculating it, so the performance can be improved by having a global register that holds this.  Still, in this case the interrupt command is better for performance and is less lines of code.  

Summary: Numeric code "4" remains unknown for now, "5" has been replaced by a better alternative and "6" seems to still be useful, although I think I'd still opt for string manipulation which I know that I can control over an undocumented feature.


Tuesday, 12 June 2012

Undocumented feature - interrupt - part three

Continuing from part two where we looked at "0" and "1"...



2 - Extract filename


This seems to extract the filename part of a full path, removing the directory structure.  Here's some example code for you...



interrupt(2,"C:\temp\test.txt")
filename = $result

In this case "filename" will be populated with "text.txt".  This does seem to be a simple case of string manipulation, but if you support both Windows and Unix filesystems (which the company I work for do, and I expect a lot of people will if they are doing any web development) then maybe it's not so simple...



filename = "C:\temp\test.txt"
pos = $rscan(filename,"\";for Windows
if ( pos < 1 )
  pos = $rscan(filename,"/";for Unix
endif
filename = filename[pos+1]



So this requires a numeric local variable and a few extra lines of code to achieve.  I tested for 2,000,000 iterations...



  • interrupt = 00:09.35, 00:09.30, 00:09.33 (over 9 seconds)
  • $rscan (Windows first) = 00:14.72, 00:14.75, 00:14.66 (under 15 seconds)
  • $rscan (Unix first) = 00:16.38, 00:16.41, 00:16.31 (over 16 seconds)

Unfortunately $rscan is a pretty slow function, but as they could be multiple folder delimiters in the string, I don't see how it can be avoided.  You have to choose in your code whether to put Windows or Unix first, unless you have a global setting somewhere which tells you which the application is running on, in which case you could limit this to a single $rscan.  

Whilst interrupt does perform better in this case, I would say that it is more than likely negligible, given the number of iterations.  Therefore, I'd choose to use the alternative, as I know that I can rely on it working in future.

3 - Extract file path


This seems to extract the file path part of a full path, removing the filename.  Here's an example...



interrupt(3,"C:\temp\test.txt")
filepath = $result

In this case "filepath" will be populated with "C:\temp\".  The alternative to this is therefore going to consist of a similar bit of string manipulation...

filepath = "C:\temp\test.txt"
pos = $rscan(filepath,"\";for Windows
if ( pos < 1 )
  pos = $rscan(filepath,"/";for Unix
endif
filepath = filepath[1:pos]


So there's no need to measure the performance of this, the different will be very similar.

Summary: Numeric codes "2" and "3" do seem to be useful and perform better than the alternatives.  However, the performance difference is probably not enough to consider using the interrupt command, as it will be less maintainable and risky moving forwards.  I'll continue in the next part.

Friday, 18 May 2012

Performance of list processing

As mentioned in my previous posts, performance is a key factor.  The lovely Uniface list is effectively string a delimited string, as you know, which means we're back to string manipulation, which we know is costly.  Unfortunately there are no arrays or similar available, so we make do.


As far as I can see, there are four ways to process a list....

  1. getitem with a counter

    count = 0
    $status = 1
    while ( $status > 0 )
      count = count+1
      getitem temp,list,count
    endwhile

  2. getitem/id with a counter

    count = 0
    $status = 1
    while ( $status > 0 )
      count = count+1
      getitem/id temp,list,count
    endwhile

  3. getitem with a destructive list

    count = 0
    while ( list != "" )
      count = count+1
      getitem temp,list,1 
      delitem list,1
    endwhile

  4. getitem with a reverse destructive list 

    count = 0
    while ( list != "" )
      count = count+1
      getitem temp,list,-1
      delitem list,-1
    endwhile
These loops all use local variables and the list is pre-built with 20,000 items like...

"1= ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890"

  1. 00:06.58, 00:06.54, 00:06.69 (just under 7 seconds)
  2. 00:06.85, 00:06.89, 00:06.84 (just under 7 seconds)
  3. 01:02.16, 01:01.87, 01:01.91 (just over 1 minute)
  4. 00:06.61, 00:06.63, 00:06.72 (just under 7 seconds)
There is obviously a clear loser here, never do a destructive list!  I think the main reason for this is that the getitem must have to scan through the string, but the delitem is then causing the whole list to be rebuilt - very costly!  

Now I shall try again but with a pre-built list of 200,000 items, the same as those before...

  1. 01:06.55, 01:06.38, 01:05.99 (just over 1 minute)
  2. 01:19.22, 01:19.88, 01:19.36 (around 1.3 minutes)
  3. -
  4. 01:05.38, 01:06.59, 01:05.45 (just over 1 minute)
This shows that the next worst is the getitem/id, whereas the remaining two are pretty close.  The reason I think the reverse destructive list works fairly well is that the list is being shortened each time, which means there is a smaller string to scan.  However, finding the first item must be quicker than finding the last, implying that the scan always happens from the first character.  What this probably means, although the numbers are too close to really prove this, is that the reverse destructive starts to perform better for really really long lists, but the plain getitem performs just as well for shorter lists.

Summary: When processing a list it is best to use either a getitem with a counter or a reverse destructive list, as these both perform well for normal sized lists.

Wednesday, 16 May 2012

Performance of string manipulation - part two

In part one I looked at the different ways of storing a string during string manipulation, and found that using a variable was by far quicker than using a field.  In this next part, I'm going to look at the different ways of building up the string.  I can think of only two different ways...

  • Concatenation (using $concat)
  • Indirection (eg. "%%string1%%string2%%%")

So I put these to the test with the following four strings...

"ABCDEFGHIJKLMNOPQRSTUVWXYZ "
"01234567890 "
"abcdefghijklmnopqrstuvwxyz "
"01234567890 "

...holding the value in a local variable and iterating 20,000,000 times...

  • Concatenation = 01:03.08, 01:03.71, 01:03.t64 (just over 1 minute)
  • Indirection = 01:02.01, 01:01.74, 01:01.98 (just over 1 minute)

The difference is almost negligible, as I had to go to so many iterations before it could be detected.  Indirection does pip concatenation to the post though, by a whisker.

I then decided to try building up a larger string, by starting with the first string and adding the other three, then taking that string and adding the other three again, and so on.  This time I also used a local variable but iterating only 20,000 times...

  • Concatenation = 00:56.41, 00:56.02, 00:56.37 (just under 1 minute)
  • Indirection = 00:55.61, 00:56.96, 00:56.92 (just under 1 minute)

Again the difference is pretty negligible, proving that in this case, size really doesn't matter.

Summary: Using concatenation or indirection doesn't really make a difference.

Performance of string manipulation - part one

One thing that every developer fights with (or should!!) is performance.  It's ok writing an application that works well for one developer sat messing about on a development server that only he is using, but it is very different when it's thousands of users all hitting the same server, under realistic but heavy load.


One particularly costly task is string manipulation.  Building up a string can use a relatively large chunk of memory and take a surprising amount of processor power.  So I decided to perform some performance tests to see how this could be improved.


The first test I did was comparing the use of a local variable against a non-database field.  I did this test by taking the following string...


" ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890"


...and then using putitem/id with a counter to add this 20,000 times, with the following results...

  • Non-database field = 02:42.14, 02:44.64, 02:43.44 (almost 3 minutes).
  • Local variable = 00:00.22, 00:00.23, 00:00.22 (less than 1 second).
  • Component variable = 00:00.22, 00:00.22, 00:00.22 (less than 1 second).
  • Global variable = 00:00.22, 00:00.22, 00:00.23 (less than 1 second.


As you can see, when manipulating a string you should never use a field to hold the string.  Having said that, it doesn't seem to make any difference which type of variable you use.  I continued testing the different types of variables with 200,000 and 2,000,000 iterations, without seeing the times deviate from each other.

Summary: Use a variable (any kind of variable) but not a field.