Testing for special cases isn't free, and this case seems rare. But the
= code processes 32 bytes at a time, while the e. does just one. Might
be worth doing in the engine; certainly you should do it in your code.
Henry Rich
On 11/10/2020 5:21 PM, Joseph Novakovich wrote:
Should this instead be considered a performance bug in 'e.'?
On 11/10/20, Joseph Novakovich <[email protected]> wrote:
The change is replacing the lines
b=. dat e. LF NB. or fd in chopstring
c=. dat e. sd
with
b=. dat = LF
c=. dat = {.sd
in 'chopstring' and 'fixdsv'
Joseph
On 11/10/20, Henry Rich <[email protected]> wrote:
I would offer an opinion, except I can't figure out what the change is.
Henry Rich
On 11/10/2020 1:25 PM, Joseph Novakovich wrote:
Hello,
I noticed a spot for performance improvement in 'fixdsv' and
'chopstring'. I opened two pull requests on github for the base9
library and the tables/dsv addon:
https://github.com/jsoftware/tables_dsv/pull/1
https://github.com/jsoftware/base9/pull/1
Basically, bitmasks were using 'e.' to find occurrences of a single
char in the input. Using '=' instead seems to give around 10-20%
speedup.
Joseph
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
