Standard library praise and challenge
- Posted by jeremy (admin) Sep 11, 2011
- 3473 views
Just some standard library praise. I was recently working with a library retrieved from the archive that was written pre 4.x. I'm not going to mention the library or author. Anyway, I was working on taking advantage of some of the standard library routines instead of the ones written in the library that accomplish the same task. I ran across ltrim, rtrim and trim. Those methods trim whitespace from the left, right or both sides of a sequence. In the standard library we have trim_head, trim_tail and trim which accomplish the same task, except that they will trim anything you want by using an optional second parameter trim(content, what = " \t\r\n") basically. Anyway... the ones written in the library I was working on were pretty simple and looked fine to me at first glance. However, one benchmark I had setup was parsing a 25mb file using the library.
Stock from the archive the library took 21 seconds to complete. Simply removing the local implementations of ltrim, rtrim and trim and using trim_head, trim_tail and trim instead from the standard library parsing time dropped to 16 seconds. That's a 24% increase in performance by a simple search/replace operation using the new standard library.
This is what the new standard libary is all about. A large collection of group maintained/peer audited/performance tested routines. Not only do we get a large number of common functions to use instead of having each programmer reinvent the wheel with each new project, we also get everyone's head wrapped around a single problem and the very best solution possible.
So... this was just a bit of praise about the standard library but also a challenge to Euphoria users. Look at the source for your favorite standard library routines. Do you see a way they can be improved? Do you see a way to make them faster? Do you see a way to make them more robust? If so, create a ticket and let the development team know! 2 eyes are better than 1, 100 eyes are better than 50.
Jeremy
