Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize nodes access #35

Open
kenoh opened this issue Oct 8, 2014 · 4 comments
Open

Optimize nodes access #35

kenoh opened this issue Oct 8, 2014 · 4 comments

Comments

@kenoh
Copy link

kenoh commented Oct 8, 2014

Hi,
on long arrays adding new items is really slow. I presume it is because of chained-list-like implementation. Therefore I would like to optimize the library.
So far I came up with two things:

  • add "last" pointer which would point to the last child, therefore improving adding new items to constant time access
  • add some form of index-pointer table for constant time access using concrete index

Please, state your ideas on this, state possible pitfalls. Thanks.

@penduin
Copy link
Member

penduin commented Oct 8, 2014

That's a really good idea! Our uses of WJElement have been heavier on
the reading/iterating parts than building large structures, but that's
beginning to change and naturally we want WJE to be good for any
purpose. :^)

The "last" pointer should give lots of bang for the buck, and not be
too tough to implement. A pointer table is a good idea too, more
involved but likely well worth it. Minego will probably have more
meaningful advice about this, but it sounds great to me!

On 10/8/14, kenoh [email protected] wrote:

Hi,
on long arrays adding new items is really slow. I presume it is because of
chained-list-like implementation. Therefore I would like to optimize the
library.
So far I came up with two things:

  • add "last" pointer which would point to the last child, therefore
    improving adding new items to constant time access
  • add some form of index-pointer table for constant time access using
    concrete index
    Please, state your ideas on this, state possible pitfalls. Thanks.

Reply to this email directly or view it on GitHub:
#35

@minego
Copy link
Member

minego commented Oct 8, 2014

How big of an array are we talking about?

I don't have an objection to adding a lastChild pointer. It will require
updating that pointer correctly in a number of different places
(WJEDetach, WJEAttach, etc) but I don't see it being too difficult.

Micah

On 10/08/14 16:01, Owen Swerkstrom wrote:

That's a really good idea! Our uses of WJElement have been heavier on
the reading/iterating parts than building large structures, but that's
beginning to change and naturally we want WJE to be good for any
purpose. :^)

The "last" pointer should give lots of bang for the buck, and not be
too tough to implement. A pointer table is a good idea too, more
involved but likely well worth it. Minego will probably have more
meaningful advice about this, but it sounds great to me!

On 10/8/14, kenoh [email protected] wrote:

Hi,
on long arrays adding new items is really slow. I presume it is
because of
chained-list-like implementation. Therefore I would like to optimize the
library.
So far I came up with two things:

  • add "last" pointer which would point to the last child, therefore
    improving adding new items to constant time access
  • add some form of index-pointer table for constant time access using
    concrete index
    Please, state your ideas on this, state possible pitfalls. Thanks.

Reply to this email directly or view it on GitHub:
#35


Reply to this email directly or view it on GitHub
#35 (comment).

@kenoh
Copy link
Author

kenoh commented Oct 9, 2014

I was adding around 4600 records each containing 16+1 values, which gives around 78200 insertions. The program was in function _WJEIndex more than 98% of the time.

@minego
Copy link
Member

minego commented Nov 13, 2016

A last pointer has been added. I would still like to do more to improve this though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants