Adding forward iteration (Really simple implementation).

vwwv commented

2016-03-15 01:21:37 +00:00

(Migrated from github.com)

Hi !

I made a patch to add iteration in a similar fashion ets:next/2 works, mainly because I need it, but I think it might be a good idea to add this, or something like this.

The implementation is rather simple and does not take advantage of the keys being next to each other from call to call ; but I create the type move() that currently just contains key, but that can could later be extended to add the means to implement a more efficient solution (if you guys think that's something interesting I can try to implement it that way).

Btw, thanks a lot for the library, is really useful, and being 100% erlang did really help when deploying :) .

Hi ! I made a patch to add iteration in a similar fashion `ets:next/2` works, mainly because I need it, but I think it might be a good idea to add this, or something like this. The implementation is rather simple and does not take advantage of the keys being next to each other from call to call ; but I create the type `move()` that currently just contains `key`, but that can could later be extended to add the means to implement a more efficient solution (if you guys think that's something interesting I can try to implement it that way). Btw, thanks a lot for the library, is really useful, and being 100% erlang did really help when deploying :) .

krestenkrab commented

2016-03-15 07:18:48 +00:00

(Migrated from github.com)

Thanks. Looks good; what are you using it for?

vwwv commented

2016-03-16 08:38:48 +00:00

(Migrated from github.com)

what are you using it for?

Do you mean the database? It is for a project related to compute rankings over games played in a online video game (storing already hundreds of millions games, adding a bunch of thousands /seconds ).

Btw, I've tried further this pull request, and even though the result themselves seem to be ok, the process using it started getting odd messages once it tries to query the key next to last one: it returns end_of_table as it should, but then receives messages about unrelated node down notifications, and a '$cast' msg. Am I missing something about howfold_range` should be used?

> what are you using it for? Do you mean the database? It is for a project related to compute rankings over games played in a online video game (storing already hundreds of millions games, adding a bunch of thousands /seconds ). Btw, I've tried further this pull request, and even though the result themselves seem to be ok, the process using it started getting odd messages once it tries to query the key next to last one: it returns `end_of_table` as it should, but then receives messages about _unrelated node down notifications_, and a `'$cast' msg. Am I missing something about how`fold_range` should be used?

krestenkrab commented

2016-03-21 12:31:06 +00:00

(Migrated from github.com)

No, you're not missing anything; maybe you can tell me how to reproduce? The teardown after completed iteration (even for just limit=1) should not cause warning messages.

vwwv commented

2016-03-22 14:55:00 +00:00

(Migrated from github.com)

It does not happen always, I only started to get them after a while under heavy usage of it...and only got a few messages. Also got other problems, after being after a good ram usage, during sometimes even hours, suddenly it stops gc binaries and quickly consume all computer's memory; while profiling I saw that when this happen there's a process accumulating hundreds of thousands of messages. These issues might or might not be related I guess.

I'll try to find out how to reproduce in a simple way.
When this happen to me, I had 3 different hannoidb running at the same time (does this violate some constraint?) and was randomly inserting on them, then taking the smallest elements (using that with a fold of size 1 ).

Also, this happened using the last OTR version, might it be that some component from any of its dependencies behaves now differently? (I had to modify edown cause no longer did compile, but seems not to be related).

It does not happen always, I only started to get them after a while under heavy usage of it...and only got a few messages. Also got other problems, after being after a good ram usage, during sometimes even hours, suddenly it stops gc binaries and quickly consume all computer's memory; while profiling I saw that when this happen there's a process accumulating hundreds of thousands of messages. These issues might or might not be related I guess. I'll try to find out how to reproduce in a simple way. When this happen to me, I had 3 different hannoidb running at the same time (does this violate some constraint?) and was randomly inserting on them, then taking the smallest elements (using that with a fold of size 1 ). Also, this happened using the last OTR version, might it be that some component from any of its dependencies behaves now differently? (I had to modify **edown** cause no longer did compile, but seems not to be related).

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin vwwv/master:vwwv/master

git checkout vwwv/master

Merge

Merge the changes and update on Forgejo.

git checkout master

git merge --no-ff vwwv/master

git checkout master

git merge --ff-only vwwv/master

git checkout vwwv/master

git rebase master

git checkout master

git merge --no-ff vwwv/master

git checkout master

git merge --squash vwwv/master

git checkout master

git merge --ff-only vwwv/master

git checkout master

git merge vwwv/master

git push origin master

Adding forward iteration (Really simple implementation). #36

Checkout

Merge