[p4] Performance impact of "large" clients

todd.benham at kodak.com todd.benham at kodak.com
Fri Aug 7 06:12:53 PDT 2009

Ok, I need to express the other side of this argument.

I don't get it -- society seems need to be so "secure" and "protected"
these days. Why make life difficult? Are you really gaining anything?
Give the user permissions to the areas they might or probably need at a
relatively high level in the depots and then you are done (change
permissions as needed). They can use a tiny scope or a large scope in
their clients as they see fit. How many times have you had to stop what
you are doing because you get a "not in client" message from Perforce.
For scripts and tools and the like, I understand this completely. But
the focus seems to be on how to make sure users are controlled and
limited (which usually means low productivity and a lot of overhead for
setup). Sure you can start "beginners" out with narrow clients but I
don't see that many or certainly not all groups would need to write
triggers and enforcements to restrict things. Why discourage small
client if someone has a use for it? Or why make some jump through hoops
to have a large client. The examples given so far seem contrived. This
just seems like a waste of time to me for the vast majority of
developers. If you have a real need for this kind of thing, certainly go
ahead an do it. 


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of
ANH at etiglobal.net
Sent: Friday, August 07, 2009 1:51 AM
To: 'perforce-user at perforce.com'
Subject: Re: [p4] Performance impact of "large" clients

I totally agree. 

The ignored best practice, and risk of making errors, unintended
submits, is the biggest problem. 

We do have a tool that helps our users create their clients, and that
tool create clients per branch. So, if a product has main, some devel
branches and some release branches, the client generated by our tool is
only for e.g. the main branch of that product. 

And ~97% of our users use these clients as they are supposed to do. 

Our challenge is the last few users, which are competent enough to
figure out how they alter the generated clients (or create new ones by
hand), but apparently not competent enough to understand the possible
pitfalls of using the large scoped clients spanning several branches. 

We have tried the educational way. 

And what I wanted from this thread was to gain some technical arguments
that might convince them that they are actually disturbing the other
developers by locking the database. Besides running the risk of
submitting/changing files unintended as Ines examples showed.

"Luckily" some of the worst of our users are database developers, and
the argument with database locking might actually be something they can
understand. :-) Thanks to Jeff for that explanation.

Thank you all for your replies. I will head back to those developers
trying to convince them why clients spanning the entire depot are BAD. 

For the record, I think we might combine our educational effort with
some form-out, form-in triggers on client. 

Especially a form-out trigger that changes default clients to span over
//depot/sandbox/main/... instead of //depot/...

Not quite sure yet if we create a form-in trigger, the disallows these
clients, or if we just react upon it if someone creates a client we
don't like.

Once again, thanks for the replies. I good first experience with the p4
mail lists. :-)

Best regards

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Ines Heinz
Sent: Thursday, August 06, 2009 5:47 PM
To: 'perforce-user at perforce.com'
Cc: 'perforce-user at perforce.com'
Subject: Re: [p4] Performance impact of "large" clients

When we have allowed the code developers to have 
clients  that contain multiple branches, they
have not only done what Steve stated, but they 
also have mistakenly submitted changes for work
that had not been tested and reviewed.  Yes, you 
can put in triggers to help limit the pain, but
going for the simpler solution and having a 
client per branch is far safer and easier.

===========================Here is the
I go into winedev and p4 edit the wine.atd file 
because my wine label is the up and coming one --
with the really witty comments about nuttiness and hints of berry.

Then someone realizes that the wine label in 
2009kegs has a misspelling of the word blackberry,
so I go and do a quick edit of that, get my edit 
reviewed and submit.  All well and good with
separate clients, but with a wide-open client, I 
accidentally submit all my opened files -- which
submits my witty comments (some of which had not 
been spell-checked)  into the winedev
branch without the appropriate review.

=====================wide open
Client Root: /home/ines/perforce
Client View:

         cd /home/ines/perforce/winedev
         p4 edit wine.atd
         cd /home/ines/perforce/2009kegs
         p4 edit wine.atd
         p4 submit -d "quick edit to fix typo in 
blackberry"  #oops -- winedev/wine.atd is submitted!

Client Root: /home/ines/perforce/winedev
Client View:
//depot/winedev/... //ines_perforce_workspace_for_updating_docs_dev/...
Client Root: /home/ines/perforce/2009kegs
Client View:

         cd /home/ines/perforce/winedev
         p4 edit wine.atd
         cd /home/ines/perforce/2009kegs
         p4 edit wine.atd
         p4 submit -d "quick edit to fix typo in 
blackberry"  #winedev/wine.atd is not submitted!

At 07:16 AM 8/6/2009, Stephen Vance wrote:
>Large subsets for view resolution which
>increases database lock time, memory requirements, and processor
>Large have tables increase your database sizes.
>Have tables have a high churn rate increasing 
>database fragmentation and slowing down performance.
>P4V and P4Win don't fstat all files on opening, 
>but they do fstat all files, changes, jobs, etc. 
>that are displayed and in scope. Larger clients 
>increase the scope, although not necessarily 
>more than "Entire Depot View" would.
>I strongly discourage catch-all clients. It
>leaves opportunities for several mistakes and 
>best practice violations. It allows changelists 
>to span branches which violates the principle of 
>a changelist being a single logical change to a 
>codeline. It allows for sloppy or mistakenly 
>targeted integrations. Those are just two of the issues.
>Anders Kjærgaard Hansen wrote:
>>We are currently doing some housekeeping and
>>cleanup in our Perforce user database, and old unused clients.
>>We came to discuss what impact large clients
>>have on both the perforce server, but also our storage.
>>We have several users who was clients with views as //depot/... 
>>What are the impacts of these "global" clients?
>>Do p4, p4v, p4win e.g. fstat all files in a
>>client each time you open it in the application?
>>We are especially interested in hearing
>>opinions on whether we should allow these clients or not.
>>We have tools supporting creation and use of correct product scoped 
>>I hope some of you have some valuable input
>>Sorry if I'm reposting this, my first mail didn't show up so I am 
>>Best regards
>>perforce-user mailing list  -  perforce-user at perforce.com 
>Stephen Vance
>perforce-user mailing list  -  perforce-user at perforce.com 

Aura Ines Heinz
WCI LC Liaison
Lawrence Livermore National Laboratory
Phone:  (925) 423-7900
Fax: (925)423-5209
B132N R1250
perforce-user mailing list  -  perforce-user at perforce.com

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list