Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upPort List functions from JavaScript to Elm #152
Conversation
jonathanhefner
added some commits
Jan 29, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
Feb 1, 2015
Member
This looks great, nice work!
I think the last point about any, drop, etc. is interesting. It'd be good to move more code into Elm, so I'd be curious to see what this looks like and if it has performance implications.
|
This looks great, nice work! I think the last point about |
pushed a commit
that referenced
this pull request
Feb 1, 2015
evancz
merged commit c63dd04
into
elm:master
Feb 1, 2015
1 check passed
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jvoigtlaender
Feb 1, 2015
Contributor
Concerning the "implement some functions using native loops" aspect, there are already some candidate implementations for such loops in https://github.com/TheSeamau5/elm-loop.
|
Concerning the "implement some functions using native loops" aspect, there are already some candidate implementations for such loops in https://github.com/TheSeamau5/elm-loop. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jonathanhefner
Feb 1, 2015
Contributor
I created three branches to show what looping could be like for any, repeat, take, and drop:
- Using foldn
anycannot be implement viafoldn, and thus is not ported
- Using foldlWhile
repeatcannot be implemented viafoldlWhile, but a safe, less-efficient, pure-Elm version is included for consideration (note the ** in the benchmark data below)
- Using loopUntil
- all 4 functions are possible, however the iteration logic was quite confusing to write (I say this as someone who grew up writing C, C#, and Java)
When benchmarking the branches, I first ran the combined tests for just the 4 functions on a 100k element list (that's the first column). That didn't provide a clear enough picture, so then I isolated the tests for each function (that's the remaining columns). For take and drop, there were multiple tests doing similar work, so I pared it down to just one test taking or dropping 99,999 elements from a 100k element list.
| branch | All 4 | any |
repeat |
take n-1 |
drop n-1 |
|---|---|---|---|---|---|
| master | 3.15s | 1.0s | 1.4s | 1.4s | 1.1s |
| foldn | 4.0s | n/a | 1.35s | 1.65s | 1.15s |
| foldlWhile | 4.15s | 1.05s | 1.45s** | 1.6s | 1.3s |
| loopUntil | 4.65s | 1.4s | 1.55s | 1.65s | 1.35s |
|
I created three branches to show what looping could be like for
When benchmarking the branches, I first ran the combined tests for just the 4 functions on a 100k element list (that's the first column). That didn't provide a clear enough picture, so then I isolated the tests for each function (that's the remaining columns). For
|
jonathanhefner commentedJan 30, 2015
This builds off of #150, so that should be merged first.
In the same spirit as #130, I ported several List API functions from JavaScript to pure Elm. Some notes:
scanlin a separate commit because it is a tiny performance regression (1.55 -> 1.65 seconds on an old laptop for a 100k element list). The regression is due to the requisite extrareversecall.sortByin terms ofsortWithbecause that resulted in a larger performance regression (2.5 -> 3.0 seconds on an old laptop for a 100k element list). The regression is (likely) due to the extra string comparison required by the JavaScriptsortWithimplementation. If we decide the performance penalty is worth it, I can port it also.any,drop,take,repeat) which were not converted, but could be by introducing an additional 1 or 2 native functions to drive looping. Either a function likefoldlWhilethat handles early termination, and / or a function likefoldn(orRange.foldl) that handles counting without creating intermediary lists (i.e. without[1..n]). I can implement these in a separate experimental branch if anyone just wants to see what they would look like.