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

refactoring plan about improve the respond ability #223

Open
dannypsnl opened this issue Sep 14, 2024 · 1 comment
Open

refactoring plan about improve the respond ability #223

dannypsnl opened this issue Sep 14, 2024 · 1 comment
Labels
improve no new functionality, but improve current implementation

Comments

@dannypsnl
Copy link
Owner

Is your feature request related to a problem? Please describe.
The thread by default created with current-thread-custodian, which will slow down the whole DrRacket, particular if I'm working on some large project (not really large in normal scale, but racket level large).

The fundamental problem is

(set! cached-record (collect-from file-path)))]
, this collect-from is computation intensive operation, move it into a place worker seems reasonable.

Describe the solution you'd like

  1. Make a place module
  2. Create 4 workers via place module, and collect-from will be invoked via worker
  3. When worker complete the job, send a message back
  4. main-thread needs to forward result to correct record-maintainer

Describe alternatives you've considered
No idea

Additional context

I found (place-message-allowed? (make-record)) is #f, the reason are fields that involve (make-interval-map).

@dannypsnl dannypsnl added the improve no new functionality, but improve current implementation label Sep 14, 2024
@dannypsnl
Copy link
Owner Author

Now I'm thinking, if interval-map cannot cross the boundary, it seems forward every message to place is more reasonable now……Though that is a big refactoring.

@dannypsnl dannypsnl changed the title refactoring plan about improve the respondability refactoring plan about improve the respond ability Sep 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improve no new functionality, but improve current implementation
Projects
None yet
Development

No branches or pull requests

1 participant