StationEquationCollection Limited # of entries?

[Jeff_M]

I have a command that uses points set along an alignment whose description are derived from the 3d length of a coincident 3dpolyline. Those descriptions are used to create StationEquations on the alignment that mimic the 3d poly length. All works well, until there are more than 75, or so, points. The code runs through all of the steps very quickly until there somewhere between 70 & 85 (I haven't had time to discover the exact point), at which point the method StationEquations.Add(station, Convert.ToDouble(description), StationEquationType.Increasing) is called. This method goes from virtually no time to execute, to 20-30 seconds to execute.

I have tested in both VLisp/COM and .NET with identical results. Attempting to set ~2800 StationEquations is going to take ~24 hours at this rate, which is unacceptable.

Any ideas as to why this slowdown is occurring? My guess is that the StationEquation mechanism was never intended for a large number of entries.

[joantopo]

Hi Jeff.

I have tried to create manually station equations and no problem.

Have you tried to add equation stations in order? for example, station 1,station 3,station 5...  Perhaps this way is faster.

And check if there is any station duplicated before to call the method.

Regards.

[Jeff_M]

Thanks for checking that, Joan. Yes, I sort all points so they are added in order starting at the lowest station, and also verify that no duplicates exist.

[Jeff_M]

Just for fun 🙂 I added a timer to the code. This shows a definite increase in time for each successive point:

1: 0.0240 sec
2: 0.0010 sec
3: 0.0010 sec
4: 0.0010 sec
5: 0.0020 sec
6: 0.0020 sec
7: 0.0040 sec
8: 0.0040 sec
9: 0.0070 sec
10: 0.0070 sec
11: 0.0090 sec
12: 0.0110 sec
13: 0.0140 sec
14: 0.0170 sec
15: 0.0220 sec
16: 0.0290 sec
17: 0.0320 sec
18: 0.0390 sec
19: 0.0430 sec
20: 0.0480 sec
21: 0.0580 sec
22: 0.0640 sec
23: 0.1050 sec
24: 0.1080 sec
25: 0.0950 sec
26: 0.1170 sec
27: 0.1210 sec
28: 0.1290 sec
29: 0.1560 sec
30: 0.1650 sec
31: 0.1820 sec
32: 0.2410 sec
33: 0.2250 sec
34: 0.2460 sec
35: 0.2560 sec
36: 0.3140 sec
37: 0.3350 sec
38: 0.3300 sec
39: 0.3720 sec
40: 0.4340 sec
41: 0.4280 sec
42: 0.4500 sec
43: 0.5070 sec
44: 0.5240 sec
45: 0.5700 sec
46: 0.5890 sec
47: 0.6380 sec
48: 0.6930 sec
49: 0.7450 sec
50: 0.7840 sec
51: 0.8460 sec
52: 0.8921 sec
53: 0.9611 sec
54: 0.9821 sec
55: 1.0491 sec
56: 1.1311 sec
57: 1.1951 sec
58: 1.2431 sec
59: 1.3291 sec
60: 1.4111 sec
Total run time: 22.1903 sec to procees 60 points.

Closing the drawing, without saving, reopening and running again, this time with 100 points gives this:

98: 6.4614 sec
99: 6.7864 sec
100: 6.9254 sec
Total run time: 172.6899 sec to procees 100 points.

I'm attaching the code used in case anyone wants to try it. The Points were modified using the DynamicLinkPoints in Sincpac-C3D to get the station (length) of a 3dPolyline at 100 foot intervals along an alignment. So either the description or a Point UDP holds the distance along the 3dpoly.

[joantopo]

WOW! It´s amazing. It´s very strange.

I don´t like to work with equation stations because if you reverse the alignment, you can have several troubles. For example, for superelevations.

[augusto.goncalves]

Thanks for the sample drawing, indeed I could reproduce it.... not sure yet what's causing it, but I'm suspecting the database is not commiting the data as it should, so when we keep adding stations without commit, it starts getting strange...

So I made a test: instead a single transaction where you call StationEquationCollection.Add several times and commit once, I made one transaction per call to Add and commit. The time per Add was longer, as it demands a commit, but the time was constant during the whole process (as far as I tried)

[Civil3DReminders_com]

Would using a profile from the 3DPolyline and then use a profile to represent the length of the profile (3DPolyline) work instead? Then get the station values and length as a reference text in labels work? The only thing I didn't see from my short look in the SincPac was creating a profile from the 3DPolyline. Although when this post was created it wasn't in the SincPac.