I know I can edit PMC a lot faster than I can BSP.
I’m getting realtime instance results with PMC I’m editing via code against BSP that requires you to build the mesh to actually see the results and if you are checking the realtime checkbox, every action will take few seconds if not more to show ( or even minutes for large meshes ).
The question is about performances after mesh manipulation is done.
I know Epic says it is better to convert all BSP to static meshes once you done modifying it for better performances.
So I was wondering, what is faster without converting to static mesh?
Hummm I’m not sure of the context of the questions as it is practical use that determines which route has the best performance curve by observation.
Side by side at rest both static mesh or BSP should have close to identical performance curve as being objects in 3d space but it’s what these objects inherent in the form secondary requirements that could increase the performance curve by comparison.
Lets say you have a BSP box and a static mesh box at rest they would be close to being the same as far as performance goes but as you make copies the BSP’s curve would increase slightly relative to the static box due to the inherited requirements of being a BSP. If you convert the BSP to a static mesh the secondary requirements as to being a BSP are removed and could be said as being neutral with an identical performance curve relative to the static mesh box.
Now if say we applied a simple material to the BSP and a complex PBR type material to the static mesh using 4k texture images as we make copies the static mesh’s performance curve would increase relative to the BSP cube.
On the other hand.
If talking about editing performance as part of the development pipeline your current hardware configuration could become the point of performance loss, and once again relative to what I’m working on, and by just increasing RAM memory from 16 to 32 gigs I was able to decrease the loss.
as to
The reason to convert a BSP to static mesh is to remove the inherited requirements that is no longer need freeing up resources that may or may not be needed but once again decrease the performance with fancy materials.
Sorry if a bit wordy but with out context of what you are doing as to the desired goal it becomes a fist fight that can only be proven by practical application and result and not by general best practice theory.
Or
It could all mean that it’s time for an upgrade. 
Thanks for answering.
I have no problem editing the mesh on my side.
I’m working on a plugin for runtime and thinking about making it an editor plugin as well.
This is WIP of it:
I want to know how good will it be against current BSP performances wise.
Let me pre-amble my answer: I do not know anything about coding, and am only posting a reply as a devil’s advocate response.
What is the performance cost of BSP? Well, using BSP is only for white-boxing levels or maps. One of the biggest reasons BSP is used, is due to speed of iteration, and (some might say this is more important) precision - as creating a level containing multiple dimensions would make the job of an environment artist very difficult. As such, the performance cost is an abstract concept, as BSP does not occupy the same process ideology as creating modular meshes. An environment artist will not create 400 completely different park benches, they will create 1 and duplicate it.
If you think about it and take a step back, you will begin to realise that modelling tools inside the engine, or having infinitely malleable geometry to very high decimal places in face, edge, vertex is not required or warranted. What is needed, however, is faster iteration and tools for BSP.
Level and map designers build the walls, environment artists paint them. An Artist will never pick up a brick, and a level designer will never pick up a paint brush. A really good BSP tool allows for the symbiotic relationship between the two to flourish.
Binary space topology is what all level and map design begins, but not ends with.