BridgedIterables are inherently slow about ghidra_bridge HOT 6 CLOSED

I have code for this eval command btw, I just haven't managed to access the special variables like currentProgram on the remote side yet. Can push this later.

from ghidra_bridge.

The list() idea is the simplest, but as you note, may run into problems down the line. I'd be interested in seeing your eval suggestion.

Unix sockets aren't something that I'm keen on - I do a lot of my work on Windows as well, so ghidra_bridge needs to be cross-platform.

from ghidra_bridge.

Currently trying to create a PoC with UnixStreamSockets, which would be trivial, but fails because the SocketServer module in ghidra Jython doesn't provide UnixStreamSockets...
This would obviously be some flag or OS detection, I agree with you that cross platform support should be the goal. But the potential order of magnitude speedup would still justify some extra logic for this IMO. Especially for headless analysis tasks which probably run on some linux server anyway.

The eval code I have is fairly simple, I just added a remote_eval function somewhere that sends a string that gets evaluated inside eval() and the result gets sent back. But I don't understand how to access the namespace and context yet. Maybe I am greatly underestimating the complexity needed for this.

That feature could then be wrapped in some IPython magic so:

%gidra_eval
[ f.name for f in currentProgram.functionManger.getFunctions(True)]

Would send the entire cell to the server to be evaluated and only return the result.

from ghidra_bridge.

The basic idea around eval can be seen in fmagin@3584047

I am not sure how to support accessing the relevant variables and if it is possible to access those on the client side too somehow

from ghidra_bridge.

I managed a trick to at least benchmark this, so I can illustrate what kind of speed up this would yield:

In [28]: %time len([f.name for f in currentProgram.functionManager.getFunctions(True)])                                                                                                             
CPU times: user 20.6 s, sys: 3.78 s, total: 24.4 s
Wall time: 3min 12s
Out[28]: 9118

In [29]: %time b.bridge.remote_eval("len([f.name for f in self.handle_dict['%s'].local_obj.functionManager.getFunctions(True)])" % currentProgram._bridge_handle)                                   
CPU times: user 1.31 ms, sys: 206 µs, total: 1.51 ms
Wall time: 83.3 ms
Out[29]: 9118

so roughly a difference of the factor 2000

This might also be the hint I need to make this work with, will open a PR for this when I can at least access the currentProgram variable (which would probably be the most important variable anyway)

from ghidra_bridge.

Cheers for that, pulled most of it in with some changes, releasing as v0.0.7

from ghidra_bridge.