But the problem is adding and deleting the objects regularly it slown down the project.Because everytime i am changing the vertexand atttribute buffer to delete and add the objects , isthere any other possiblity to cull the objects..

Well, culling by creating/deleting meshes on-the-fly isnt the standard way to go (sometimes it is useful for static batching, but not on a per-frame base). Usually you just create your meshes once (eg when loading the level) and just don't render them when you cull them and delete the meshes once they are no longer needed (eg when you finish the game, load an other level etc).

Btw. using a BSP is often slower in modern game architecture then to just render a few more objects then needed. Culling is often done by checking the bounding volume (eg a simple AABB) vs the camera frustum. If you have a larger scenes, you can use additional data structure to help you culling (quad/oct trees, sweep'n'prune).

Btw. using a BSP is often slower in modern game architecture

Just going to add that it depends heavily on the data. BSP is still awesome for static corridors and similar indoor levels once you actually get it to work. For dynamic object, some kind of a room/portal system would help. The key thing here is to provide occlusion culling (via PVS), not just frustum culling and have it work only on the static data.

Also, adding and removing stuff into any tree is going to be slow. Oct-/quad-/k-d/BSP tree - doesn't matter. The fact that it's a tree means it will require doing complex queries or caching all the time. So anything less structured works better with dynamic stuff. Frustum culling on AABB arrays can easily help handle thousands of objects, no need to go fancy before your first thousand. Software occlusion culling can do about the same but that would probably take a lot more time to implement properly. Took me three full days to get it half-right (SSE, no threading) with my experience.