Windows libraries as a paper folder! (for Win 7+)

[highend]

Ok, seems that I've squished all bugs. Fine.

I'm thinking of getting rid of the permanent variable and instead build the $libDB from scratch on every script invocation.

Why?

There are a few circumstances that bother me...

When you (e.g. by accident) delete a folder that belongs to a library...
it won't be reflected in the $libDB variable (unless you edit the library file afterwards).

It's the same when you recreate that folder. $libDB won't see it.

The thing is... time.

Script execution time with $libDB being permanent:
65 msecs (with a SSD system here)

$libDB built from scratch:
250 msecs

runret(for GetLibraryPaths.exe) takes most of that time...

Opinions?

[Enternal]

My opinion is permanent variables are not needed. The difference between 65ms and 250ms is significant but the 250ms is not that long in the first place. And the most important thing is Libraries usually don't change that often. Therefore, "wasting" 250ms once in a while should not be much of an issue.

[Filehero]

I'm competely with Enternal. In my daily usage scenarios I change my Libraries folder structure every once in a super while only.

[highend]

Ok,

uploaded v1.1.0. With this test release all library paths are built from scratch on each invocation.
This reflects all changes on the physical file system for all folders that are in the libraries.

It prints the time in msecs in the status line after each run. There isn't much that I can do to
optimize that... Apart from turning GetLibraryPaths.exe into something like a background service
which could be queried via WM_COPYDATA messages

Does v1.1.0 work for you?

[Enternal]

Yep! Works perfectly for me!

[highend]

How many msecs does it take on your machine (from - to)?

[Enternal]

First ten runs:
421 msec
265 msec
280 msec
265 msec
265 msec
280 msec
265 msec
265 msec
281 msec
281 msec

I then realized that I might get faster speed if I disable my antivirus and also my anti-executable program. Results (10):
187 msec
187 msec
188 msec
187 msec
187 msec
171 msec
171 msec
187 msec
187 msec
187 msec

I'm also using SSD.

[highend]

That's not too bad. HDD users may have higher times but I can't test that atm :X

I guess it's possible to live with such execution times.

[Filehero]

I will post my results when back from work (evening).

[klownboy]

I'm awake now! I agree, not much sense in maintaining a perm variable especially when they're larger ones and you can obtain decent speeds without they're use. My list of perm variable is growing. My speeds were 203, 156, 171, 171, 171, 171 ,171, 171, 203, 156....so I'd say fast enough. SSD, but the certainly not the latest and greatest.

[Filehero]

Code: Select all

5812
203
203
203
203
XY_Restart
125
109
110
110
109

On SSD.

For me it's real-time.

Idea: reuse the paper:Libraries tab if it already exists.


Cheers,
Filehero

[highend]

Idea: reuse the paper:Libraries tab if it already exists.

Done.

@Changelog:
v1.1.1
• Added: - Only open one tab with paper:Libraries. If it exists, switch to it

[Filehero]

Done.