Timeline for Why is the new PositionIndex horribly slow?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 17, 2014 at 11:24 | comment | added | Mr.Wizard | Thanks for getting this fixed. :-) | |
| Jul 16, 2014 at 22:27 | comment | added | Taliesin Beynon | @JacobAkkerboom added myself. Thanks! | |
| Jul 15, 2014 at 11:31 | vote | accept | Mr.Wizard | ||
| Jul 15, 2014 at 6:09 | comment | added | Mr.Wizard | Anyway, thanks again for your attention and affirmation that this will be corrected. | |
| Jul 15, 2014 at 6:08 | comment | added | Mr.Wizard | Thanks again for taking the time to answer one of my Questions, even one as discourteous as this. Thank you also for the analysis. I was aware of cases where PositionIndex appears more favorable but as you said the bottom line is: "PositionIndex should be strictly faster than myPosIdx (since) it is written in C." Also your point about complexity is taken, but if I am not mistaken computational complexity is multidimensional: it is not merely about e.g. list length but also other factors (e.g. number of unique elements), therefore I stand by my statement that it has poor complexity. | |
| Jul 15, 2014 at 5:22 | comment | added | Michael E2 | @Szabolcs ?GeneralUtilities*` ... Many functions have a brief synopsis or code. | |
| Jul 15, 2014 at 4:34 | comment | added | Szabolcs | Would love to learn more about GeneralUtilities` . | |
| Jul 15, 2014 at 4:31 | comment | added | ciao | I look forward to seeing this improved - as bad as it is with the user-side GatherBy implementation, it's even worse off against this | |
| Jul 15, 2014 at 2:16 | history | answered | Taliesin Beynon | CC BY-SA 3.0 |