_ci.GetFileProperties : bad performance; workarounds?

M Wickardt · Post by **M Wickardt** » Mon Aug 07, 2006 1:20 pm

Hi Sourcegear,

I need the "shared files" information from the command line client.

I patched the "listfolder" command in VaultCmdLineClient.cs, bij adding the following to WriteFolder:

Code: Select all

Hashtable hs = _ci.Repository.Shares;

// in the foreach:
bool bIsShared = hs.ContainsKey(file.ID);
if (bIsShared) _xml.AddPair("isshared", "yes");
else _xml.AddPair("isshared", "no"); ;

if (bIsShared) props = _ci.GetFileProperties(file.FullPath, file.ObjVerID);

This last command takes forever; about 5-7 seconds per file. It's not a lan issue, I connect to localhost on the server itself.

It does work; in a property on props, the shared paths appear.

Is there a quicker way to accomplish this?
NB: I also noticed, in the GUI client, this is also slow (right-click on file -> Properties -> 5 - 7 seconds waiting).

Here's the output btw, I added some extra fields to the xml output for debugging.

Code: Select all


listfolder $/ont/s/rp/comn gives:

<vault>

<folder name="$/ont/s/rp/comn">

 <file name="xreflib.p" version="4" length="36697" objectid="1087" objectversionid="3907" ispinned="no" fullpath="3/20/23/1067/1080/1087" isshared="yes" shares="$/prod/s/rp/comn/xreflib.p|$/test/s/rp/comn/xreflib.p" latestversion="4" status="Missing" />

 <file name="gettabledesc.p" version="1" length="1206" objectid="1083" objectversionid="1170" ispinned="no" fullpath="3/20/23/1067/1080/1083" isshared="yes" shares="$/test/s/rp/comn/gettabledesc.p|$/prod/s/rp/comn/gettabledesc.p" latestversion="1" status="Missing" />

 <file name="persproc.p" version="1" length="1065" objectid="1085" objectversionid="1172" ispinned="no" fullpath="3/20/23/1067/1080/1085" isshared="yes" shares="$/prod/s/rp/comn/persproc.p|$/test/s/rp/comn/persproc.p" latestversion="1" status="Missing" />

 <file name="comn.p" version="2" length="11739" objectid="1081" objectversionid="2107" ispinned="no" fullpath="3/20/23/1067/1080/1081" isshared="yes" shares="$/prod/s/rp/comn/comn.p|$/test/s/rp/comn/comn.p" latestversion="2" status="Missing" />

 <file name="osfunclib.p" version="1" length="4854" objectid="1084" objectversionid="1171" ispinned="no" fullpath="3/20/23/1067/1080/1084" isshared="yes" shares="$/prod/s/rp/comn/osfunclib.p|$/test/s/rp/comn/osfunclib.p" latestversion="1" status="Missing" />

 <file name="excelfrombrowse.p" version="1" length="17335" objectid="1082" objectversionid="1169" ispinned="no" fullpath="3/20/23/1067/1080/1082" isshared="yes" shares="$/prod/s/rp/comn/excelfrombrowse.p|$/test/s/rp/comn/excelfrombrowse.p" latestversion="1" status="Missing" />

 <file name="xrefbatch.p" version="2" length="2885" objectid="1086" objectversionid="2828" ispinned="no" fullpath="3/20/23/1067/1080/1086" isshared="yes" shares="$/prod/s/rp/comn/xrefbatch.p|$/test/s/rp/comn/xrefbatch.p" latestversion="2" status="Missing" />

</folder>

</vault>

Best regards, M (Tijs) Wickardt, Bertus Distributie NL

System:
Version Check: This Vault client is version 3.5.0.4741
Version Check: Your Vault server is version 3.5.0.4741
Server: XP Pro SP2 / SQL Express 2005

Post by **jclausius** » Mon Aug 07, 2006 1:26 pm

Try walking through the Client Instance's local Tree Cache. A match on the File's ID would be shared.

M Wickardt · Post by **M Wickardt** » Mon Aug 07, 2006 1:30 pm

Thanks for the *very* quick reply.

We don't work with local files though (except the checked out ones), so I guess this isn't of much use to us.

Is this assumption correct?

Best Regards, M (Tijs) Wickardt

M Wickardt · Post by **M Wickardt** » Mon Aug 07, 2006 1:34 pm

A full listfolder from $/ goes rather quickly though (about 2 seconds).
So I guess I could cache this once, and parse the xml output manually in search for duplicate ID's, meaning shared files?

How does the 2 seconds for everything (+- 5000 files) relate to the 5-7 seconds for 1 single file? Why does the call perform so poorly? Just interested.

Best regards, M (Tijs) Wickardt

Post by **jclausius** » Mon Aug 07, 2006 2:05 pm

M Wickardt wrote:Thanks for the *very* quick reply.

We don't work with local files though (except the checked out ones), so I guess this isn't of much use to us.

Is this assumption correct?

Best Regards, M (Tijs) Wickardt

No. That is incorrect.

The Vault Client Instance has a "picture" of the Repository Tree. This Tree Cache is in effect regardless of your settings.

You should be looking at walking the Tree Cache with the File's ID to detect the share.

Post by **jclausius** » Mon Aug 07, 2006 2:11 pm

M Wickardt wrote:A full listfolder from $/ goes rather quickly though (about 2 seconds).
So I guess I could cache this once, and parse the xml output manually in search for duplicate ID's, meaning shared files?

Seems like a different route with the TreeCache.

M Wickardt wrote:How does the 2 seconds for everything (+- 5000 files) relate to the 5-7 seconds for 1 single file? Why does the call perform so poorly? Just interested.

Best regards, M (Tijs) Wickardt

Get Properties is making a call to the Vault Server for each file. The Vault Server will do some other checks on the file (and security checks if you're using Folder security), then it must return the results in the SOAP message.

M Wickardt · Post by **M Wickardt** » Mon Aug 07, 2006 2:36 pm

Thank you for the replies, I'll investigate further along with your advice.

Best regards, M (Tijs) Wickardt

M Wickardt · Post by **M Wickardt** » Tue Aug 08, 2006 11:03 am

Works like a charm, I make an IDictionary object of all the shares, populated by a walk through the client tree cache. Less than 150 ms overhead (whole operation, not -per file-) for adding a "shares" property (with pin version if pinned) to the output xml list.

Best regards, M (Tijs) Wickardt