ZeroNoRyouki

@XyFreak : I'm not making any promises because I've yet to verify if it's technically feasible, but if you would be able to "fetch a bunch of stats" with a single call, what stats would those be?

What is the problem your are trying to fix?

Please keep in mind that I've run all my test against OC 1.6.2.7 as that is the minimum version I'm targeting. So I don't think this is an 1.7.x problem

Hi there, I've made another test tonight.

I wrote a very dummy implementation for my OC API with a barebone class that's is a straight implementation of OC's Environment, SidedEnvironment and ManagedPeripheral

No parent classes, no calls to the actual reactor code, just the most dummy and fast implementations of getConnected / getEnergyStored : https://pastebin.com/3Pfs1J99

An instance of that class is created when the computer port TileEntity is created and returned to OC when the cable ask the port for the SidedEnvironment capability

So there is no extra code that can slow things down. But the delay is still there, your test program is still registering it

Please keep in mind that I can't go back to the 0.4.5.30 implementation becase that version relied on OC SimpleComponent / class Transformer to work and I was asked by the OC guys to stop doing that : https://github.com/MightyPirates/OpenComputers/issues/2371

I'm pleased that the problem is not the @Callback annotation because I like it way more than the string lookup 

We may have to bring the OC's dev in at this point ...

So today I put together a small ManagedPeripheral that use the same stings lookup that DE use with just a couple of methods and the delay did not go away. Implementing ManagedEnvironment and NamedBlock too changed nothing. I've also switched to the SidedEnvironment capability from the Environment one because the former is queried first by the OC cable than the latter but no luck.

I've also traced how callbacks are executed by OC / Lua and the code path is identical for my owns and the DE ones. 

The only big differences between ER and DE at this point is that I use capabilities to interact directly with the OC cables while DE need the adapter block but I'm not sure this is significant

The VM JIT could also have a play at this (maybe DE use the same method used by it's callback while drawing the big energy orb on the screen and so that method is called so much that the JIT optimized the hell of out it) and so I've let the other reactor-controller program I've used so far run for an hour or so but again, no differences

Not sure what else is there to try at the moment...

Hi there!

So, I've run the "test" program in my 1.10.2 devenv and got the same bunch of 1s. I then changed getEnergyStored() to always return a fixed values without querying the reactor and tested again: same result. This is good, as it's not the reactor code that it's slowing thigs down

What I basically have, code wise, is an OC'Enviroment with a bunch of @Callbacks (getEnergyStored, getFuelAmount, etc). DE also implement an Enviroment but it use a string lookup (from ManagedPeripheral) to call the methods. If OC is using reflection to find the correct method on every method invocation we could have and explanation of the delay. I'll have to look around a bit more in OC code

Z