search

SlimeVoid / CollaborativeMod

GNU Lesser General Public License v3.0
1 stars 0 forks source link

Figure out why matching algorithm takes so long and find a way to optimize it #15

Open Tarig0 opened 11 years ago

Tarig0 commented 11 years ago

Is it possible to have a matching spinner in the interface and have the container search without blocking (freezing) the client or server?

Eurymachus commented 11 years ago

It is a strange one. We need to time the various segments of the checks.

On 9 Sep 2013, at 14:41, "Allen Cook" notifications@github.com wrote:

Is is possible to have a matching spinner in the interface and have the container search without blocking (freezing) the client or server?

— Reply to this email directly or view it on GitHub.

Eurymachus commented 11 years ago

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client >> server >> client network/lag issue.

Tarig0 commented 11 years ago

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones notifications@github.comwrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312 .

Tarig0 commented 11 years ago

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones notifications@github.comwrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312 .

Eurymachus commented 11 years ago

I've found the bottleneck!

OnCraftMatrixChanged gets called about 30 times + when opening the GUI. I lol'd!!!

Sent from my iPhone 4

On 9 Sep 2013, at 15:46, "Allen Cook" notifications@github.com wrote:

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones notifications@github.comwrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312 .

— Reply to this email directly or view it on GitHub.

Tarig0 commented 11 years ago

wow why would we do that

On Mon, Sep 9, 2013 at 12:42 PM, Greg Jones notifications@github.comwrote:

I've found the bottleneck!

OnCraftMatrixChanged gets called about 30 times + when opening the GUI. I lol'd!!!

Sent from my iPhone 4

On 9 Sep 2013, at 15:46, "Allen Cook" notifications@github.com wrote:

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones notifications@github.comwrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHub< https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24093360 .

Eurymachus commented 11 years ago

It's not on purpose. It's due to the sub calls from setSlot in InventorySubUpdate and onInventoryChanged method

Sent from my iPhone 4

On 9 Sep 2013, at 17:56, "Allen Cook" notifications@github.com wrote:

wow why would we do that

On Mon, Sep 9, 2013 at 12:42 PM, Greg Jones notifications@github.comwrote:

I've found the bottleneck!

OnCraftMatrixChanged gets called about 30 times + when opening the GUI. I lol'd!!!

Sent from my iPhone 4

On 9 Sep 2013, at 15:46, "Allen Cook" notifications@github.com wrote:

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones notifications@github.comwrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHub< https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24093360 .

— Reply to this email directly or view it on GitHub.

Tarig0 commented 11 years ago

I was assuming redpower did that as well

On Mon, Sep 9, 2013 at 1:00 PM, Greg Jones notifications@github.com wrote:

It's not on purpose. It's due to the sub calls from setSlot in InventorySubUpdate and onInventoryChanged method

Sent from my iPhone 4

On 9 Sep 2013, at 17:56, "Allen Cook" notifications@github.com wrote:

wow why would we do that

On Mon, Sep 9, 2013 at 12:42 PM, Greg Jones notifications@github.comwrote:

I've found the bottleneck!

OnCraftMatrixChanged gets called about 30 times + when opening the GUI. I lol'd!!!

Sent from my iPhone 4

On 9 Sep 2013, at 15:46, "Allen Cook" notifications@github.com wrote:

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones < notifications@github.com>wrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHub<

https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24093360>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24095156 .

Eurymachus commented 11 years ago

Never lagged.

I'm working it out

Hit me when you're online.

Sent from my iPhone 4

On 9 Sep 2013, at 18:19, "Allen Cook" notifications@github.com wrote:

I was assuming redpower did that as well

On Mon, Sep 9, 2013 at 1:00 PM, Greg Jones notifications@github.com wrote:

It's not on purpose. It's due to the sub calls from setSlot in InventorySubUpdate and onInventoryChanged method

Sent from my iPhone 4

On 9 Sep 2013, at 17:56, "Allen Cook" notifications@github.com wrote:

wow why would we do that

On Mon, Sep 9, 2013 at 12:42 PM, Greg Jones notifications@github.comwrote:

I've found the bottleneck!

OnCraftMatrixChanged gets called about 30 times + when opening the GUI. I lol'd!!!

Sent from my iPhone 4

On 9 Sep 2013, at 15:46, "Allen Cook" notifications@github.com wrote:

that way even with the lag at least the client doesn't block

On Mon, Sep 9, 2013 at 10:45 AM, Allen Cook alcook16@gmail.com wrote:

I think we need to have a isremote flag set so that the checks only happen server side. This could be why things are slow.

On Mon, Sep 9, 2013 at 10:29 AM, Greg Jones < notifications@github.com>wrote:

I'm wondering if I's to do with your HashMap checks. But that doesnt usually take that long....

The one thing is that the 'lag' doesn't seem to happen when testing via eclipse (i.e. locally)... which leads me to believe that there is a client

server >> client network/lag issue.

— Reply to this email directly or view it on GitHub<

https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24080312>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24093360>

.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/SlimeVoid/CollaborativeMod/issues/15#issuecomment-24095156 .

— Reply to this email directly or view it on GitHub.

Tarig0 commented 10 years ago

hmm had an idea, could we do matching algorithm on client only and tell the server only when the inventory changes, that way it doesnt' matter how many people are using workbenches all the work is done on each client