Vista - Technique: autoloaded functions

Technique: autoloaded functions

This is related to a discussion "what do you prefer: scripts or dot-sourced
functions". Perhaps there is an alternative that I'm going to discuss:
autoloaded functions.

Perhaps this technique is not something new but I have not seen a discussion
yet. This technique avoids: 1) using a code as a script - it may be not good
if it is called/parsed many times; 2) using a code as a pre-dot-sourced
function - it may be not good if you have lots of such functions but just a
few of them are actually used in a session - redundant parsing again.

The idea: in a folder included in %PATH% create a script with the same name
as a function, say, Test-Autoload, i.e. Test-Autoload.ps1 (see comments for
the rest of explanation):

[SCRIPT]

##
## Test-Autoload.ps1
## Autoloaded function Test-Autoload
##

# script parameters: the same as function below has
param($param1, $param2)

# global function Test-Autoload: "global" is important
function global:Test-Autoload($param1, $param2)
{
Write-Host "This is Test-Autoload FUNCTION with $param1, $param2"
$param1 + $param2
}

# here may be some global initialization executed once
Write-Host "This is Test-Autoload SCRIPT with $param1, $param2"

# now the function is recalled: the first and the last time from here
Test-Autoload $param1 $param2

----------

Now we are ready to use autoloaded function Test-Autoload; note: it is
important to use the same syntax as if the function Test-Autoload is already
available (no dot-sourcing, no script path or script extension, that is why
the script must be in the %PATH%):

TEST

for($i = 0; $i -lt 3; ++$i) {
Test-Autoload $i $i
}

----------

OUTPUT

This is Test-Autoload SCRIPT with 0, 0
This is Test-Autoload FUNCTION with 0, 0
0
This is Test-Autoload FUNCTION with 1, 1
2
This is Test-Autoload FUNCTION with 2, 2
4

----------

Thus, when we call Test-Autoload the first time we actually call the script
Test-Autoload.ps1. It creates the global function Test-Autoload and recalls
it passing in there the same parameters. When we call Test-Autoload next
times we actually call this global function not a script.

So far this technique looks working fine for me. Are there any caveats that
I do not see yet?

--
Thanks,
Roman

The same technique can be used to load PowerShell function libraries.

For example: sometimes I use nice functions Measure-Since and Measure-Till
written by Jeffrey Snover:
http://blogs.msdn.com/powershell/arc...yTimeps1-.aspx.
I keep these functions in a file Library-Time.ps1 together with other
date/time related utilities.

The tiny annoyance is that I use them relatively seldom, so I do not quite
like the line

. Library-Time.ps1

in my profile because in most cases this library is not actually used during
a session, but it is always loaded and consumes some resources.

Well, I can try to load the library just in the body of a function that uses
it:

function Do-SmthWithTime
{
. Library-Time.ps1
...
}

It is fine if I call Do-SmthWithTime once or twice. It is not fine if I call
it hundred of times because in this case Library-Time.ps1 is loaded every
time.

So, I change Library-Time.ps1 to be autoloaded:

# global(!) empty dummy function with the same name as a library
function global:Library-Time {}

# global(!) utility functions
function global:Measure-TimeSpan([TimeSpan]$Span, $Units=$Null)
{..}
function global:Measure-Since([DateTime]$Time, $Units=$Null)
{..}
function global:Measure-Till([DateTime]$Time, $Units=$Null)
{..}

I also change the function Do-SmthWithTime:

function Do-SmthWithTime
{
Library-Time
...
}

Now Library-Time.ps1 is loaded only at the first call of Library-Time (no
matter from this function or not). Then just a dummy empty global function
Library-Time is called - this is the only overhead for using this approach.

--
Thanks,
Roman

Roman Kuzmin wrote:
> Technique: autoloaded functions
>
> This is related to a discussion "what do you prefer: scripts or dot-sourced
> functions". Perhaps there is an alternative that I'm going to discuss:
> autoloaded functions.
>
> Perhaps this technique is not something new but I have not seen a discussion
> yet. This technique avoids: 1) using a code as a script - it may be not good
> if it is called/parsed many times; 2) using a code as a pre-dot-sourced
> function - it may be not good if you have lots of such functions but just a
> few of them are actually used in a session - redundant parsing again.

I like the idea. It's clever! But is executing scripts really that slow?
I mean, do you actually notice a slowdown executing scripts stored in
files as opposed to stored in memory?

Because if it's not noticeable, then maybe it's just extra work and
structure for no apparent benefit...

"Adam Milazzo" <adamm@san.rr.com> wrote in message
> do you actually notice a slowdown executing scripts stored in files as
> opposed to stored in memory?

Yes, definitely, but the answer completely depends on the number of calls.
It may be not a good idea to call a script from inside of a loop with many
iterations. If you create a function that calls a script you perhaps have to
remember not to call this function from such a loop, too.

On the other hand, as it was said, it may be not a good idea to dot-source
everything that can be potentially used. I believe in a few months/years
everybody will have tons of really useful code but used only occasionally.

> Because if it's not noticeable, then maybe it's just extra work and
> structure for no apparent benefit...

This technique is a way of optimisation. It may be used from the very
beginning or it may be used only when performance problem happens. I do not
really know what is better - it depends on many factors.

--
Thanks,
Roman

Roman Kuzmin wrote:
> "Adam Milazzo" <adamm@san.rr.com> wrote in message
>> do you actually notice a slowdown executing scripts stored in files as
>> opposed to stored in memory?
>
> Yes, definitely, but the answer completely depends on the number of calls.
> It may be not a good idea to call a script from inside of a loop with many
> iterations. If you create a function that calls a script you perhaps have to
> remember not to call this function from such a loop, too.
>
> This technique is a way of optimisation. It may be used from the very
> beginning or it may be used only when performance problem happens. I do not
> really know what is better - it depends on many factors.

Well it's just that you keep saying it "may" not be a good idea. I'm
just wondering whether it's actually, noticeably slow using scripts in
files, or is it just theoretical?

> whether it's actually, noticeably slow using scripts in files, or is it
> just theoretical?

Without really serious investigation I have just measured my autoloaded
function Get-Stamp and the same script (here is what it does, but perhaps it
does not matter for the picture):

([System.DateTime]::Now).ToString('_yyMMdd_HHmmss')

Results are average of 10000 repetitions (with no parallel file I/O
operations in other processes when the difference is even larger as I could
see):

Autoloaded:
TotalMilliseconds : 0.969
Script:
TotalMilliseconds : 3.3545
Difference:
2.3855 ms

Suppose the results above are reliable and there is 2.3855 ms difference at
every call. Is it a performance issue in practice? For some tasks - yes. Let
I have to do something (i.e. call a function or a script) for all files on
my drive C:\ (sure, not this silly Get-Stamp job), then in my case I am
about to call a procedure 271577 times, estimated difference is
271577*2.3855 = 647846.9335 milliseconds or ~10.8 minutes - it is a
significant performance issue. I have a number of files on other drives, too


--
Thanks,
Roman

Roman Kuzmin wrote:
>> whether it's actually, noticeably slow using scripts in files, or is it
>> just theoretical?
>
> Without really serious investigation I have just measured my autoloaded
> function Get-Stamp and the same script (here is what it does, but perhaps it
> does not matter for the picture):
>
> ([System.DateTime]::Now).ToString('_yyMMdd_HHmmss')
>
> Results are average of 10000 repetitions (with no parallel file I/O
> operations in other processes when the difference is even larger as I could
> see):
>
> Autoloaded:
> TotalMilliseconds : 0.969
> Script:
> TotalMilliseconds : 3.3545
> Difference:
> 2.3855 ms
>
> Suppose the results above are reliable and there is 2.3855 ms difference at
> every call. Is it a performance issue in practice? For some tasks - yes. Let
> I have to do something (i.e. call a function or a script) for all files on
> my drive C:\ (sure, not this silly Get-Stamp job), then in my case I am
> about to call a procedure 271577 times, estimated difference is
> 271577*2.3855 = 647846.9335 milliseconds or ~10.8 minutes - it is a
> significant performance issue. I have a number of files on other drives, too
>

In that case perhaps, but I think no matter what you do, it's going to
be expensive if you do it 272 thousand times. :-)