Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal for windows unicode #132

Open
sonoro1234 opened this issue Dec 6, 2019 · 1 comment
Open

proposal for windows unicode #132

sonoro1234 opened this issue Dec 6, 2019 · 1 comment

Comments

@sonoro1234
Copy link

After dicussion in PR #57 my proposal would be to wrap all functions in lfs taking a path so that it is converted to unicode. Functions that return paths would convert them from unicode to UTF-8.

In order to keep compability io.open and other Lua functions taking paths would be overloaded by functions from lfs (lfs.open lfs.remove) so that would be lfs 1.8 (instead of 2.0)

@sonoro1234
Copy link
Author

sonoro1234 commented Feb 23, 2021

Doing a test to check size of all a directory tree I could measure the speed of https://github.com/luapower/fs against luafilesystem and https://github.com/sonoro1234/luafilesystem:

It took arround 36 seconds for both lfs and 8 seconds for fs.
It is unicode aware (providing functions for opening files, etc ) and has a different directory iterator providing filename and a fileinfo object.

This fileinfo object is the key to speed (as I could check making a lfs_ffi.lua version of it): you can avoid calling lfs.attributes which is the main cause of the slow performance.
implemented for win32 only by now in https://github.com/sonoro1234/luafilesystem branch newiterator

I think that future versions of lfs should take a look at https://github.com/luapower/fs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant