Inlines?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Inlines?

Paul Ramsey
Can anyone shed some light on our inlining strategy? It seems really... odd.
Like picked at random, in ConvexHull, the following methods are inlined if GEOS_INLINE is on (it is by default).

ConvexHull::ConvexHull(const geom::Geometry* newGeometry)
ConvexHull::~ConvexHull()
ConvexHull::extractCoordinates(const geom::Geometry* geom)

Now... none of these feel like they are particularly hot path to me. The constructor, destructor, and a private utilty method.
I ask mostly because there's a lot of this .inl stuff scattered around and it doesn't seem particularly helpful.
If there's some history I'd be intrigued to know.
P
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Inlines?

Sandro Santilli-4
On Tue, Aug 11, 2020 at 03:06:00PM -0700, Paul Ramsey wrote:

> Can anyone shed some light on our inlining strategy? It seems really... odd.
> Like picked at random, in ConvexHull, the following methods are inlined if GEOS_INLINE is on (it is by default).
>
> ConvexHull::ConvexHull(const geom::Geometry* newGeometry)
> ConvexHull::~ConvexHull()
> ConvexHull::extractCoordinates(const geom::Geometry* geom)
>
> Now... none of these feel like they are particularly hot path to me. The constructor, destructor, and a private utilty method.
> I ask mostly because there's a lot of this .inl stuff scattered around and it doesn't seem particularly helpful.
> If there's some history I'd be intrigued to know.

I can't remember why those things ended up in .inl.
I guess destructors were there to try at debugging some issues
with virtual tables not being correct when destructors were inlined
(so to turn inlining off)

--strk;
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Inlines?

Paul Ramsey


> On Aug 12, 2020, at 2:52 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Tue, Aug 11, 2020 at 03:06:00PM -0700, Paul Ramsey wrote:
>> Can anyone shed some light on our inlining strategy? It seems really... odd.
>> Like picked at random, in ConvexHull, the following methods are inlined if GEOS_INLINE is on (it is by default).
>>
>> ConvexHull::ConvexHull(const geom::Geometry* newGeometry)
>> ConvexHull::~ConvexHull()
>> ConvexHull::extractCoordinates(const geom::Geometry* geom)
>>
>> Now... none of these feel like they are particularly hot path to me. The constructor, destructor, and a private utilty method.
>> I ask mostly because there's a lot of this .inl stuff scattered around and it doesn't seem particularly helpful.
>> If there's some history I'd be intrigued to know.
>
> I can't remember why those things ended up in .inl.
> I guess destructors were there to try at debugging some issues
> with virtual tables not being correct when destructors were inlined
> (so to turn inlining off)

Going back to an old question from mloskot, would it be crazy to just put the inlined functions into the standard header, marked "inline" and use compiler flags to turn off inling if we so desire? Maybe things work better now than they did ~2007 when you laid this structure out?

P.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: Inlines?

andrew.bell.ia@gmail.com
Unless you're dealing with templates or some functions that are important to let the compiler inline so that it can "see" more code, I would just put things in the .cpp file. Functions like accessors that are used frequently should definitely be made available for inlining.

On Wed, Aug 12, 2020, 5:54 PM Paul Ramsey <[hidden email]> wrote:


> On Aug 12, 2020, at 2:52 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Tue, Aug 11, 2020 at 03:06:00PM -0700, Paul Ramsey wrote:
>> Can anyone shed some light on our inlining strategy? It seems really... odd.
>> Like picked at random, in ConvexHull, the following methods are inlined if GEOS_INLINE is on (it is by default).
>>
>> ConvexHull::ConvexHull(const geom::Geometry* newGeometry)
>> ConvexHull::~ConvexHull()
>> ConvexHull::extractCoordinates(const geom::Geometry* geom)
>>
>> Now... none of these feel like they are particularly hot path to me. The constructor, destructor, and a private utilty method.
>> I ask mostly because there's a lot of this .inl stuff scattered around and it doesn't seem particularly helpful.
>> If there's some history I'd be intrigued to know.
>
> I can't remember why those things ended up in .inl.
> I guess destructors were there to try at debugging some issues
> with virtual tables not being correct when destructors were inlined
> (so to turn inlining off)

Going back to an old question from mloskot, would it be crazy to just put the inlined functions into the standard header, marked "inline" and use compiler flags to turn off inling if we so desire? Maybe things work better now than they did ~2007 when you laid this structure out?

P.


_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel