davlee1972 opened a new issue, #41357:
URL: https://github.com/apache/arrow/issues/41357

   ### Describe the enhancement requested
   
   This is a similar request to the one below, but instead of modifying 
pyarrow.fs.FileSelector() I think this should be a @use_cache flag in 
get_file_info()..
   
   https://github.com/apache/arrow/issues/33618
   
   **The rational for this is that same as https://peps.python.org/pep-0471/**
   
   This PEP proposes including a new directory iteration function, 
os.scandir(), in the standard library. This new function adds useful 
functionality and increases the speed of os.walk() by 2-20 times (depending on 
the platform and file system) by avoiding calls to os.stat() in most cases.
   
   **The downside of using cache is documented below. We're sacrificing some 
integrity for speed**
   
   The DirEntry objects are relatively dumb – the name and path attributes are 
obviously always cached, and the is_X and stat methods cache their values 
(immediately on Windows via FindNextFile, and on first use on POSIX systems via 
a stat system call) and never refetch from the system.
   
   **Here's the justification for this on Window platforms**
   
   scanning directories followed of stat() calls works ok and is slower than 
scandir()..
   But for REMOTE filesystems mounted on windows like SAMBA mounts this is 
super painfully slow.
   Every stat() call turns into a SAMBA API call so using Arrow FileSelector() 
to search for files just doesn't work.
   I tried using get_file_info() with a FileSelector() on 3,000 files and it 
didn't return back anything until 15 minutes passed.
   
   Running a simple ms-dos DIR /s command on a SAMBA folder gave me everything 
back in 15 seconds..
   
   
   ### Component(s)
   
   C++, Python


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to