[physfs] What are the real benefits of PhysFS ?

[Jeremy]

It's faster because there is normally less file IO. The files are less
fragmented, so there is less seeking, The files are compressed so there is
less reading. The cpu cost of the uncompression is typically insignificant
compared to the IO cost.

On Thu, Jul 16, 2009 at 3:34 PM, Daniel Aquino <mr.danielaquino at gmail.com>wrote:

> Well I was just looking for even more reasons to use it.
>
> By operate do you mean you can also edit files in the archive?
>
> Why is it faster, doesn't the unzipping cause delay too?
>
> Can you specify a byte pointer to load? so I could append an archive to my
> binary which would make switching versions as seemless as clicking on an
> exe?
>
>
> Do you normally release archives with only changed files or would you
> simply replace the entire main archive?
>
> I'm trying to think of the best practice for releasing updates while still
> being able to roll back if at all possible....
>
> Sent from my iPhone
>
> On Jul 16, 2009, at 12:58 PM, Jeremy <jswigart at gmail.com> wrote:
>
> You are asking a question with which you discount the answers as part of
> the question.
> Not a very fair question. What are the benefits of driving a car, other
> than getting someplace in a timely manner, other than not being exposed to
> the elements, etc.
>
> Being able to treat all files as if they were raw files with no regard to
> whether or not they are in an archive is a significant simplification of the
> file IO process. The by product of that simplifying the update process by
> the mount order of archives is a nice added benefit. In general loading data
> from large pack files has performance benefits as well, such as
> significantly reduced load times. Physfs gives you that benefit in a way
> that essentially allows you to operate on the files as if they were just raw
> files in a folder, whether they are or not. It's common during development
> of a project to have all the files loose in the folders, since they change
> so often. Come release time, you throw them in a zip and load times are
> improved, and it's much easier to release and update, while saving a bit of
> on disk space, at no additional work on the projects file system.
>
> On Thu, Jul 16, 2009 at 11:49 AM, Daniel Aquino <<mr.danielaquino at gmail.com>
> mr.danielaquino at gmail.com> wrote:
>
>> As I sit here I'm wondering what the benefits really are for putting
>> in the work needed to get physfs into a game...
>>
>> I obviously know that I could provide updates as zip's that could
>> easily be rolled back.
>>
>> The user can also easily override any file by adding his own to the
>> write folder.
>>
>> You could specify paths to other zips/directories on the cli and it
>> all just flows there is no need to point at 1 physical directory and
>> then glue it all all together your self...
>>
>> But beyond that what is the benefits ?
>>
>> I was trying to reduce the complexity of rolling out version with
>> multiple files... Previously I use to just push a new exe and it was
>> simple to click on the exe you wanted to launch... Now that I have lua
>> and other dll's in the project it's a multi file update that
>> overwrites previous entries which looses the ability to pick the
>> version you want to play in...   So I was figuring I could come up
>> with a small boot strapper that would load up a bunch of locations
>> using physfs, present a list of exe's to the end user, then extract it
>> and launch it... Then the concept would be that the exe knows (perhaps
>> based on date strings in the file names) which updates came previous
>> to it self and doesn't load up any new ones...  This way updates could
>> come in a zip and you can still play multiple versions...
>>
>> Any ideas?
>> _______________________________________________
>> physfs mailing list
>>  <physfs at icculus.org>physfs at icculus.org
>>  <http://icculus.org/mailman/listinfo/physfs>
>> http://icculus.org/mailman/listinfo/physfs
>>
>
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
>
>
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20090716/6bd58f0b/attachment.htm>