Closed bblack closed 8 years ago
Hi @bblack, Yeah, that's still an issue for me as well, I don't really see how I can improve this given all the constraints due to serialization (given you can quit Atom with a CSV file open I have to load early everything needed in order to deserialize the data when the workspace is loaded).
Can it be delay-loaded while the workspace is loading?
Also @abe33 , why do you need to serialize anything on close? Shouldn't tablr be able to be opened from "first principles"?
@tnrich The reason is that if you have any table editor open when quitting Atom you probably want it restored as it's done with the classical text editor. This is especially interesting if the editor has unsaved changes, so that you don't lose them when reopening Atom. Since table editors are pane items, they are serialized along with the workspace, and restored with the workspace as well.
The issue here is that the workspace is deserialized before any packages gets activated. They have been loaded so that you can register deserializers, but not activated yet. Delaying the registration of a deserializer at activation time will lead to a deserializer not found
error when the workspace is deserialized.
Now that I think more about it, maybe I can hack around by registering a dummy deserializer that will just return a placeholder item until the package gets activated and all the classes lazily loaded.
Timecop routinely reports activation times of over a second for tablr. For example, of 79 packages, tablr is by far the slowest to activate. For some context, the slowest 6 for me on my most recent load (which looks typical) are:
Most packages take < 10 ms to activate.