A co-worker stated that he "knew for a fact" that there are performance
issues in accessing a directory over a UNC path versus using a mapped drive
to the same location. (The bare UNC path scenario is supposedly slower.)
Apparently this occurs when interating directories with large numbers of
files. Has anyone heard of such a thing? If so, is there a link to an
authoritative discussion of the issue? Thanks.
It's a function of how many network drives (CD-Roms in the drives) etc. that
you may have mapped. Windows Explorer first has to read the file header
information, associations and icon information and then compose the Explorer
view. You can use Network Places instead as it only reads file and directory
name information so the presentation is generally faster.
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
"Jeff Johnson" wrote:
>A co-worker stated that he "knew for a fact" that there are performance
>issues in accessing a directory over a UNC path versus using a mapped drive
>to the same location. (The bare UNC path scenario is supposedly slower.)
>Apparently this occurs when interating directories with large numbers of
>files. Has anyone heard of such a thing? If so, is there a link to an
>authoritative discussion of the issue? Thanks.
>
"Dave Patrick" <DSPatrick@nospam.gmail.com> wrote in message
news:O6WfsAEdKHA.4708@TK2MSFTNGP02.phx.gbl...
>>A co-worker stated that he "knew for a fact" that there are performance
>>issues in accessing a directory over a UNC path versus using a mapped
>>drive to the same location. (The bare UNC path scenario is supposedly
>>slower.) Apparently this occurs when interating directories with large
>>numbers of files. Has anyone heard of such a thing? If so, is there a link
>>to an authoritative discussion of the issue? Thanks.
> It's a function of how many network drives (CD-Roms in the drives) etc.
> that you may have mapped. Windows Explorer first has to read the file
> header information, associations and icon information and then compose the
> Explorer view. You can use Network Places instead as it only reads file
> and directory name information so the presentation is generally faster.
Your answer would seem to suggest that mapped drives might be slightly
slower than UNC paths. But my co-worker states the opposite: mapped drives
perform faster than UNC paths. And this isn't just Windows Explorer; it's
any file access, such as batch processes through code. Any idea?
"Jeff Johnson" <i.get@enough.spam> wrote in message
news:e7oS%23fCeKHA.5808@TK2MSFTNGP06.phx.gbl...
> "Dave Patrick" <DSPatrick@nospam.gmail.com> wrote in message
> news:O6WfsAEdKHA.4708@TK2MSFTNGP02.phx.gbl...
>
>>>A co-worker stated that he "knew for a fact" that there are performance
>>>issues in accessing a directory over a UNC path versus using a mapped
>>>drive to the same location. (The bare UNC path scenario is supposedly
>>>slower.) Apparently this occurs when interating directories with large
>>>numbers of files. Has anyone heard of such a thing? If so, is there a
>>>link to an authoritative discussion of the issue? Thanks.
>
>> It's a function of how many network drives (CD-Roms in the drives) etc.
>> that you may have mapped. Windows Explorer first has to read the file
>> header information, associations and icon information and then compose
>> the Explorer view. You can use Network Places instead as it only reads
>> file and directory name information so the presentation is generally
>> faster.
>
> Your answer would seem to suggest that mapped drives might be slightly
> slower than UNC paths. But my co-worker states the opposite: mapped drives
> perform faster than UNC paths. And this isn't just Windows Explorer; it's
> any file access, such as batch processes through code. Any idea?
I think your or co-worker is wrong.
UNC Paths have less overhead.
Mapped drives also have connection issues, disconnection issues, timeout
issues, "browse dialog" issues, and probably a few other issues I haven't
thought of. UNC Paths have none of those issues other than some of the old
style dialog boxes don't acknowledge a UNC Shortcut.
UNC Paths = the future
Mapped Drives = the dinosaur past and the Novell past.
--
Phillip Windell
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
> A co-worker stated that he "knew for a fact" that there are performance
> issues in accessing a directory over a UNC path versus using a mapped
> drive to the same location.
Define performance. Time to read/write files? Or time to browse through
the explorer to find a path.
UI access to either kind will suffer if you put an extreme number of files
in them.
Phillip Windell <philwindell@hotmail.com> wrote:
<snip>
>
> I think your or co-worker is wrong.
> UNC Paths have less overhead.
> Mapped drives also have connection issues, disconnection issues,
> timeout issues, "browse dialog" issues, and probably a few other
> issues I haven't thought of. UNC Paths have none of those issues
> other than some of the old style dialog boxes don't acknowledge a UNC
> Shortcut.
> UNC Paths = the future
> Mapped Drives = the dinosaur past and the Novell past.
Hi, Phil!
<devil's advocate mode>
I have no problems with drive mappings, disconnections, timeouts, or
anything like that. I hate UNC paths. I mean, I use them to access stuff
myself sometimes, but I don't want my clients or the desktop apps they use
to have to know (or to see!) where on a network or server their stuff is
actually located. A drive mapping is a variable. It lets me change things
around behind the scenes without users or software ever having to know about
it. If you've ever used software such as AutoCAD which has all its internal
links/xrefs using UNC paths, you will know what pain and heartache are
involved in a server replacement.
</devil's advocate mode>
"Bill Kearney" <wkearney99@hotmail.com> wrote in message
news:AsKdnVAIWLvTUIPWnZ2dnUVZ_sadnZ2d@speakeasy.net...
>> A co-worker stated that he "knew for a fact" that there are performance
>> issues in accessing a directory over a UNC path versus using a mapped
>> drive to the same location.
>
> Define performance. Time to read/write files? Or time to browse through
> the explorer to find a path.
>
> UI access to either kind will suffer if you put an extreme number of files
> in them.
Not UI at all. This is a server-based program (a service, I believe)
enumerating and reading files on another server.
Basically I don't believe what my co-worker said and just in case he was
right I wanted documentation.
In message <#BXIMMFeKHA.5808@TK2MSFTNGP06.phx.gbl> "Lanwench [MVP -
Exchange]" <lanwench@heybuddy.donotsendme.unsolicitedmailatyahoo.com>
was claimed to have wrote:
>I have no problems with drive mappings, disconnections, timeouts, or
>anything like that. I hate UNC paths.
You're probably lucky enough to have stable connectivity between client
and server. Not everyone has this luxury at all times, I've got users
on wifi due to cabling limitations, plus mobile users.
This message is coming to you over a VPN tunneled through another VPN
from approximately 35,000 in the air.
>I mean, I use them to access stuff
>myself sometimes, but I don't want my clients or the desktop apps they use
>to have to know (or to see!) where on a network or server their stuff is
>actually located. A drive mapping is a variable. It lets me change things
>around behind the scenes without users or software ever having to know about
>it.
DFS (with or without replication) solves this reasonably well.
Personally I'm still annoyed and disappointed that Microsoft didn't do
better with "libraries" in Windows 7, being able to administratively
manage libraries and include UNC paths within libraries would finally
kick the drive letter habit by making network paths just as easy for
users as drive letters are.
In message <e7oS#fCeKHA.5808@TK2MSFTNGP06.phx.gbl> "Jeff Johnson"
<i.get@enough.spam> was claimed to have wrote:
>Your answer would seem to suggest that mapped drives might be slightly
>slower than UNC paths. But my co-worker states the opposite: mapped drives
>perform faster than UNC paths. And this isn't just Windows Explorer; it's
>any file access, such as batch processes through code. Any idea?
Mapped drives tend to slow down Explorer's performance since Explorer
tries to open them to show space used and other details. However,
because Explorer has already opened the connection, the very next access
is somewhat faster since you don't have to wait for machine name
resolution (DNS, NetBIOS, arp, whatever)
Beyond that, actual file copying, random access times, etc should all be
the same.
"Lanwench [MVP - Exchange]" > Hi, Phil!
>
> <devil's advocate mode>
....and you make such a cute little devil too :-)
Yes,..I understand what you are saying.
But I pretty much go along with what Dave Warren is saying. I almost
mentioned DFS but he already did.
I handle UNC paths by creating Shortcuts and placing them on the Desktop or
My Docs or whatever is convenient. They can even be "browsed-through" from
the root of their location with most dialog boxes, and by changing their
Icon to look like a Folder the users just view and treat them like folders
and most of the time the users never see the difference. Yes you can see
the path details in the address bar of Explorer,...but I don't really care
about that. I don't go with "security by obscurity" and keep my NTFS
permissions tight and clean,...so they can only get to what they are allowed
no matter path details they see & know,..or don't see & know.
--
Phillip Windell
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Dave Warren <dave-usenet@djwcomputers.com> wrote:
> In message <#BXIMMFeKHA.5808@TK2MSFTNGP06.phx.gbl> "Lanwench [MVP -
> Exchange]" <lanwench@heybuddy.donotsendme.unsolicitedmailatyahoo.com>
> was claimed to have wrote:
>
>> I have no problems with drive mappings, disconnections, timeouts, or
>> anything like that. I hate UNC paths.
>
> You're probably lucky enough to have stable connectivity between
> client and server.
Not always, but I don't have problems with drive mapping because of that.
> Not everyone has this luxury at all times, I've
> got users on wifi due to cabling limitations,
I always work on wifi here - and I use mapped drives w/no real problems.
That said, I really don't like to rely on wifi in my clients' AD
environments because if there's an issue with connectivity it will affect
more than just drive mapping stability.
> plus mobile users.
My mobile users use RDP/TS/Citrix, and Outlook Anywhere for mail, so it's a
non-issue :)
>
> This message is coming to you over a VPN tunneled through another VPN
> from approximately 35,000 in the air.
lol - this is the next step after the time-honored "Guess where I'm calling
from right now!"
>
>> I mean, I use them to access stuff
>> myself sometimes, but I don't want my clients or the desktop apps
>> they use to have to know (or to see!) where on a network or server
>> their stuff is actually located. A drive mapping is a variable. It
>> lets me change things around behind the scenes without users or
>> software ever having to know about it.
>
> DFS (with or without replication) solves this reasonably well.
Yep, but it's more complex and may not be an option in a small shop.
>
> Personally I'm still annoyed and disappointed that Microsoft didn't do
> better with "libraries" in Windows 7, being able to administratively
> manage libraries and include UNC paths within libraries would finally
> kick the drive letter habit by making network paths just as easy for
> users as drive letters are.
I will freely confess to having no idea whatsoever what a Win7 library is.
Yet. :)
Posting Permissions
Reply With Quote
Bookmarks