Agreed on memory. And, you may also need to increase JVM memory in Workstation to edit the VSI.
We do not know the exact characteristics of the service, so it is difficult to provide specific guidance; however, you might consider the following:
Incoming Request and Response payload sizes can cause VSIs to become rather large. I have seen VSIs in the 2GB range. They are difficult to edit, and I usually look for some type of alternative strategy.
I caution against developing service images that contain high numbers of specific responses as this can create situations where your service begins to 'boil the ocean' in terms of response scenarios. To use an analogy, your service is a forest and a specific response is a tree within the forest. When you add a high number of responses, it becomes more difficult to debug why the incoming request did not find the 'tree' you were looking for.
I also consider the makeup of the operations within a virtual service image. Think of it similar to the way a data modeler models a database table. A DBA would not mix operations related to products with operations related to customer data. Similarly, modeling a VSI based upon a strategy that considers ways to separate VSIs using the URIs Base Path can help you separate a single large service image into smaller, more manageable images. This is possible because multiple VSMs can listen on the same port and the Base Path provides the tie breaker that sends the request to the appropriate service.