Does it make any difference in performance or resource consumption if I use links or copies?

[Jennifer Boyle]

For copyable items, I can either use copies or links.  Does it make any difference which I use?

[KarenMichelle Lane]

In your Inventory, a link is a smaller bit of data as it {points} to the original object in your Inventory Asset Database rather than duplicating the complete Object and its Descriptors. Not having the Asset Server Database Schema available, all I can surmise is that a {Link} includes its own unique UUID + the UUID of the original object. These are the database keys.

Based on my Modeling experiences, for non-copyable object {Links}, the {State} of the pointed to Original Object is not stored with the {Link} Entry.

I've verified this based on my observance of Shoes and Mesh objects not retaining the color [and other] settings when used in different outfits. The Original Object seems to remember the values I last set.

So to answer your performance question, [iMHO] I think links take up less space in your SL Viewer's Local Cache and thus would load faster if only compromised of 2 UUIDs.

~~~~~~~~~~~~~~~~~~~

Also in your question was the qualifying phrase "For copyable items"!

For your own Inventory, Links can reference copyable and non-copyable items. In all cases when you purchase anything you receive at lease one copy of all it's components into your own Inventory Database.

The advantage of copyable & modifiable items is that you can have copies of them each configured in many different {states}. I have jewelry like this that is adjusted for the 2 sizes of avatar shapes I use in-world.  In my own case, these {adjusted} jewelry pieces are then {linked} to in many of my Ready to Wear Outfits. Of course you can do this with any copyable object that you have modify permissions for  like hair, tats, dress prims, shoes & heels and so on.

 

[Original Jewelry Piece] UUID [a...] {Original State Data}

|

+--- [Original Jewelry Piece (Copy 1)] UUID [b...]  {Adjusted Large State Data}

|          |

|          +------------- UUID [d...] {Link} in Outfit 1 -> UUID [b...]

|          +------------- UUID [f...]  {Link} in Outfit 2 -> UUID [b...]

|

+--- [Original Jewelry Piece (Copy 2)] UUID [c...]  {Adjusted Small State Data}

           |

           +------------- UUID [e...]  {Link} in Outfit 3 -> UUID [c...]

           +------------- UUID [g...]  {Link} in Outfit 4 -> UUID [c...]

I learned some of this back when I used to run several Region Servers on the OS GRID. The Link explanation I'm deriving from Linden Researches own explanation of the feature.