Le mercredi 23 septembre 2015 à 05:15 -0700, Páll Haraldsson a écrit : > > > On Monday, September 21, 2015 at 12:18:12 AM UTC, Daniel Carrera > wrote: > > > > On 21 September 2015 at 01:36, Páll Haraldsson < > > [email protected]> wrote: > > > I know about @devec but wander how close Julia is also able to > > > match the speed of its looks with more condensed code or MATLAB > > > -like or functional programming language style. What are the most > > > interesting issue numbers to look at, if you were to try to help? > > > I'm guessing its not one of the easier "up-for-grabs" issues, for > > > relative newbies like me.. > > > > > Sorry, I don't understand what you are trying to ask. > > > I really just meant, with the loop, the code goes from 2 to 6 lines. > Is three times LOC a drawback of Julia to get speed (note you do not > *have to* expand if speed isn't critical, and much code isn't). > Compared to C/C++ that is competetive, but may not be against say > MATLAB. The code was already fast there and didn't need a loop. I > assume/understand this is a temporary situation, and maybe I or > anyone can help fix it. > > > > > > > Another thing I saw: > > > "String is not a concrete type. Consider ASCIIString or > > > UTF8String. " > > > > > > This would not apply in Python, UTF8, UTF16 etc. could be in a > > > type (a new one that can hold the others through composition?) > > > that "just works" [fast]? Windows uses UTF16 and then choosing > > > UTF8String there would be bad? > > > > > No, that's not what it means. UTF8String will be fast too. In Julia > > there are two kinds of types: concrete types, and abstract types. A > > concrete are things like: > > > Thanks for answering. I knew about abstract vs. concrete. What I > meant here, "UTF8String will be fast" yes, but if you are on Windows > the API uses UTF16 and I assume you'll be converting needlessly back > and forth. That might not be a problem, you are maybe I/O-limited. > But if not, will Windows always be second class platform, for code > that assumes UTF8 (or wise versa..)? Will Julia at least compete will > with Python for string handling..? This has been discussed a few times already. Passing strings to the OS isn't usually a bottleneck. For example, after listing the contents of a directory, converting the paths from UTF-16 to UTF-8 for display is much cheaper than the I/O operations involved.
In use cases where it really matters, UTF16String will work fine. After all, in Julia, there are no built-in types: all custom string types can work as well and as fast as the default one. Regards
