Yes, What prompted my question was Tim Holy: "String is not a concrete type. Consider ASCIIString or UTF8String." Maybe ok in this case. If he meant it as a general advise, I thought maybe a Union of the UTF encodings (and ASCII?) would be needed to be general. Or not, as you say (and I), this may never really be a speed bottleneck. At least the convert system takes care of any UTF concreat type works.
On Wednesday, September 23, 2015 at 2:03:22 PM UTC, Milan Bouchet-Valat wrote: > > 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 >
