Re: Some questions on Cimple

CIMPLE will always produce a larger footprint than hand tailored, but is much easier to develop.
A common library does not prevent providers from being unloaded, but reduces thrashing when you change classes a lot.
Lots of individual providers does not cause repetition of common classes because you don't write providers for common classes, only the final terminals.
It just means provider footprint may be less.

So there is no major concern either way, of combining providers or not.
Either way makes no real difference at all.

 
Kirk  Augustin
11821 NW McNamee Rd
Portland, OR 97231


HM: 503-289-4356


>________________________________
> From: Johnny Hwang <[email protected]>
>To: "Siddegowda, Sowmya" <[email protected]>; "[email protected]" <[email protected]> 
>Sent: Monday, December 30, 2013 2:01 PM
>Subject: RE: Some questions on Cimple
> 
>
>
> 
>Hello Sowmya,
> 
>W/ CIMPLE, you definitely get a huge boost in speed of development, as I’ve worked with both native CMPI and with CIMPLE. As for optimized code, unfortunately I never got around to doing benchmarks, but with today’s overpowered processors, it probably shouldn’t be too much of a worry. You’re using Pegasus anyway, and that’s another major bottleneck when it comes to footprint.
> 
>As for one vs multiple, you could also do a hybrid profile-based approach based upon usage. It’s easier to start with a common library and break it apart into smaller chunks, than to start with multiple libraries and consolidate them into one library. With Cimple, I’ve tried both approaches, but different packagings are suited for different expected SMI-S client environments. 
> 
>Hope this helps,
>Johnny Hwang
> 
>From:Siddegowda, Sowmya [mailto:[email protected]] 
>Sent: Monday, December 30, 2013 1:49 PM
>To: [email protected]
>Subject: Some questions on Cimple
> 
>Hi,
> 
>We are in the process of writing storage array providers with Pegasus & CMPI interface. We wanted to know:
>1.        If using CIMPLE framework provides,
>a.       Clear benefit in terms of optimized code resulting in smaller footprint over handcrafted providers. 
>b.      Other benefits in terms of speed of development etc.
>2.       CIMPLE provider generation traces the classes all the way up the hierarchy link. Are there any best practices/thumb rules on how to consolidate the classes? 
>a.       One common library (.so) for all the classes will increase the size & also will not allow CIMOM to unload the provider
>b.      One unique library (.so) for each class will have too many (unwanted) repetitive common classes in hierarchy
> 
>Thanks
>Sowmya
>
>