 | | | slow render options SOLVED! | slow render options SOLVED! 2004-04-05 - By Anthony Rossano
Back
I don't know what ALL the problems are, but I know some have to do with
the filename requirements for windows. Depending on software used,
file server used, etc, each file might need to be accessible as a 8.3
filename or a standard length file (32 char? I can't remember..) AND,
here's the real probem, be available as both case sensitive and case
insensitive.
This means that apps have to do all kinds of funky things to process
lists of file names to make sure it all works.
This rears its ugly head particularly badly in Samba, the windows file
server emulator, running on Linux or other unix. A ferw thousand files
and you could be waiting for five minutes when opening the directory on
a Mac or a PC.
The fastest solution I have seen is FTP. In situations where the server
has 20,000 images or more in a directory sometimes I just use FTP...
faster network access as well. It would be a neat feature to add to
XSI: read and write files with ftp protocol.
The second best seems to be NFS running on a unix system, but then
mounting that to Windows efficiently is hard.
ATR
On Mon, 05 Apr 2004 11:40:36 -0400, Sylvain Moreau wrote:
> I am struggling with this problem for years.
> In my experience large numbers of file have a major impact on a system
> responsiveness. Unfortunately I really don't know much about what is causing
> this and how to fix it. Sometime I notice obvious performance problem (I
> recently ask XP to open all JPEG with Photoshop by default, XP responded by
> being 10 times slower...) but most of the time this problem is really
> insidious. The system is getting slower and slower without obvious reason. A
> large number of file in the same directory is never a good idea but I think
> there are other similar problems. I had a case where a hierarchy of
> directories was very slow to access. No folders in the hierarchy contained
> more than a 1000 pictures but the whole hierarchy contained more than a 100
> 000.
>
> If anybody knows more about how to efficiently deal with large numbers of
> files please comments.
>
> syl
>
> p.s. I am not a Linux user but I remember having similar problems on Unix.
> System architects and animators probably don't have the same point of view
> on what is a 'reasonable' number of documents.
>
>
> -- -- Original Message -- --
> From: "kim aldis" <kim@(protected)>
> To: <XSI@(protected)>
> Sent: Saturday, April 03, 2004 2:59 AM
> Subject: RE: slow render options SOLVED!
>
>
>> That'd be it. Many pictures take years to scan. The other reason not to
>> allow too many files in directories - and this includes simulation cache
>> files too - is that windows is just crap at dealing with large numbers.
>> Thing is, there's no clear cut rules about how many and the problems it
>> causes aren't consistent. I had an incident a couple of years ago where
>> anything between 15000 and 18000 pics in a directory gave the error 'can't
>> write to file: Printer not available'. Go figure.
>>> -- -- Original Message -- --
>>> From: "adrian" <adrian@(protected)>
>>> To: <XSI@(protected)>
>>> Sent: Friday, April 02, 2004 2:53 PM
>>> Subject: slow render options SOLVED!
>>>
>>>
>>>> you may or may not remember me waffling on about
>>> render/region options
>>>> ppgs taking YEARS to open and refresh when you changed ANY
>>> entry in the
>>> ppgbout
>>>>
>>>> finally found out it is related to how many images you have in your
>>>> Render_Pictures folder!
>>>> i have a current project that has 13,000 or so pal rendered
>>> pic files,
>>>> and the render options are very very slow
>>>> i saved the scene into a new/clean database and the render
>>> options are
>>>> really quick
>>>>
>>>> does anyone at Soft know if the fg/gi/image-output
>>> entries, in the ppg,
>>>> are refreshed every time something in the ppg is changed?
>>>> if so this behaviour needs to be modified
>>>>
>>>> ta
>>>>
>>>> a
>>>>
>>>> --
>>>> <<<<< adrian wyer - Head of 3D - MillTv >>>>>
>>>> <<<<<www.photonmap.com>>>>>>>>
>>>>
>>>>
>>>> ---
>>>> Unsubscribe? Mail Majordomo@(protected) with the
>>> following text in body:
>>>> unsubscribe xsi
>>>>
>>>
>>> ---
>>> Unsubscribe? Mail Majordomo@(protected) with the following
>>> text in body:
>>> unsubscribe xsi
>>>
>>>
>>>
>>
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo@(protected) with the following text in body:
>> unsubscribe xsi
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in body:
> unsubscribe xsi
[ Anthony Rossano ]
- CEO, Mesmer Inc -
-tel: 206.782.8004-
-fax: 206.782.8101-
http://www.mesmer.com
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|