Is vector speed depence with its size?

[yoyokits]

I have made a plot program based on vector.
The vector is in two dimension.

vector<CPlot> pPlot;

So this is like two dimension array. the first dimension is for the plot index (multiple plots) and the second dimension is CPlot that contain array of double.

vector<double> points;

Or more complete class declaration code is something like this:

class CPlot
{
public:
	CPlot(CString name, COLORREF color);
	~CPlot();

protected:
	// Name of plot which will be displayed on the legend
	CString name;
	// Container for plot points
	vector<double> points;
	// Color of the plot
	COLORREF color;

public:
	// Initialization of plot variables
	void InitPlot(CString name, COLORREF color);
	// Insert a point to the plot
	void InsertPoint(double point);
};

class CYNPlot
{
public:
	// protected constructor used by dynamic creation
	CYNPlot();
	~CYNPlot();

protected:
	CString Title, XName, YName;
	// Containner of plots which will be displayed on the screen
	vector<CPlot> pPlot;

public:
	// Initializing plot variables
	void InitPlot(CString Title, CString XName, CString YName);
	// Draw all graph component to the screen
	void Draw(CDC* pDC);
	// Insert new plot to the graph
	void InsertPlot(CString name, COLORREF color);
	// Insert a point to the selected plot
	int InsertPoint(unsigned int index, double value);	
	// Draw all existing plot
	void DrawPlot();

};

I use this plot for displaying the sensor value (20 sensors) in real time. Every second I update the view 10 times.
The problem is if the number of points is increasing, at about 500 point of 20 sensors/plots, the time of drawing is increasing also.

The looping is something like this:

getdata from 20 sensors -> Add point to 20 plots using points.push_back(point); -> Redraw the plot.

I redraw only 100 last points, not all points. It should be at constant speed, but it is getting slower and slower.

The second program, I make the vector size constant. If I add a new point I remove the first point. And it works, the speed is constant now.

My conclusion is vector dependence with its size? Is that true? Or maybe there are solution to improve the speed of vector operation?

[zdf]

I am not a STL expert but I guess each time you use “vector:: push_back” there is a chance to allocate memory for the new element. This may slow down your application. Try to use “vector:: reserve”.

I hope I correctly understood your problem.

[Philip Nicoletti]

1) as zdf mentioned, when doing a push_back() , sometimes additional
memory must be allocated and the old data copied to the new memory.

2) But also, as you keep doing the push_back(), you are increasing
memory usage. Monitor the memory when it starts to slow down.

3) Using erasing the first element prevents the memory from getting
used up. However, for a vector, this will cause asll the other
elements to be "shifted down". Since your vectors are small, this
is probably not a big deal. You might consider using deque instead
of vector.

[yoyokits]

Thank you for ZDF and Philip.
The problem is solved by limited the vector size. If i used push_back, then check the size of this vector. If the vector size reach the defined limit, I remove the first array in vector. And now, the speed is stable.

[GNiewerth]

Hi,

that´s exactly what Philip doesn´t want you to do. Because of the linear memory layout vector has to move each element one position down every time you erase the first element. If your vector contains 10 elements and you remove the first one, elements 1-9 are moved to position 0-8. For an n-element vector there are n-1 movements when removing the first element, what might be time consuming when storing a large number of elements.
You should seriously consider the use of std:eque or a circular buffer as mentioned here: STL like circular buffer

Regards,
Guido

[dude_1967]

You should seriously consider the use of std:eque...

Because std:eque (double ended queue) is designed for optimal run-time performance when inserting and / or removing elements at each end. Vector is not optimized for this, but rather for a fast operations on a contiguous memory array.

Sincerely, Chris.