0

I have a C++ object (Vision.cpp) that takes a bunch of images in its constructor. The object performs some image processing on these images and returns a result. This happens on the server side. The images were taken by the client side and sent over to the server as shown here:

Client takes image --> server receives image --> server instantiates Vision.cpp and passes in the sequence of images

The sequence of images, as expected, is heavy on memory. Should I design the Vision.cpp class to make copies of the images or should I just keep pointers to the images and force the server to not free the memory allocated for the images until Vision.cpp is done processing? I want to make copies to avoid forcing the server to keep its pointers valid, but image copying also takes time. Is there a good solution to this?

r.vengadesh
  • 1,721
  • 3
  • 20
  • 36
Cricketer
  • 2,391
  • 4
  • 24
  • 29
  • 2
    What do *"server instantiates Vision.cpp"* and *"Vision.cpp class"* mean? – Nawaz Jul 09 '13 at 06:19
  • Why not a reference? Your pointer concerns would still apply, though. – chris Jul 09 '13 at 06:20
  • or use move semantics on Vision – Enigma Jul 09 '13 at 06:20
  • 3
    if you use C++11 you can take a look at std::shared_ptr – Alexis Jul 09 '13 at 06:20
  • Move semantics would also help. – Mark Garcia Jul 09 '13 at 06:22
  • What do you mean by "Use move semantics on Vision"? – Cricketer Jul 09 '13 at 06:34
  • Move semantics are a C++11 feature that sometimes allows operations that look like copies to instead steal the memory out of one object and stick it in another, avoiding most of the copy overhead. While it can help performance, adding move semantics will probably not make your code simpler. – user2357112 Jul 09 '13 at 06:45
  • 1
    Are client and server different processes? As I see this now you should get it to work first and optimize later. For a start you should stick with the copy and rework that if you face performance problems later. – moooeeeep Jul 09 '13 at 07:21
  • They are different processes, even running on different devices. Thanks for the suggestion. – Cricketer Jul 11 '13 at 10:38

2 Answers2

0

Use references or pointers, and make sure the lifetime of the images extends past the duration of the processing. Unless the Vision object needs to retain access to the image data after the processing call, this should be relatively simple. Making all those copies would be horrible for your performance (and there'll be more copies than you realize). You're going to need to get used to thinking carefully about object ownership and lifetime in C++, because there are going to be plenty more problems that you can't handle with copies at all.

user2357112
  • 260,549
  • 28
  • 431
  • 505
  • Plenty more problems like? – Cricketer Jul 09 '13 at 06:34
  • @user2380088: When you need to share an object that doesn't support copies at all, perhaps associated with a resource like a file or a database, or when it's important that all mutative operations happen on the same version of the object instead of a bunch of copies scattered around. – user2357112 Jul 09 '13 at 06:42
0

In these cases, I typically use either:

  • Immutable data (good if you reuse/share input images). This can be a reference or maybe std::shared_ptr<const Image>. For a rendering pipeline, you could also employ a destination buffer (e.g. render destination), then the Vision is just a collection of processors which own none of the input or output images. So one scenario here is that you have a bunch of input images -- Server provides immutable references to the images to all created Visions. Then the RenderDestination asks the Vision to render to RenderDestination's bitmap. This is typically a win if you reuse images. This can result in copy (of sorts) during render, but you can reduce allocations if the destination is reused.

  • Or you can transfer the ownership of the bitmaps and use a process in place form, passing a (mutable) bitmap representation from one processor to the next processor until processing is complete. This is typically a win if you do not reuse images, but it can be costly for the Server to generate/copy/reopen those images when/if the input images are reused.

But there are several ways you can tackle this -- it depends on how you use the inputs and how you process.

justin
  • 104,054
  • 14
  • 179
  • 226