> To be clear, it's an improvement for dev experience instead of runtime
> performance, right?
Yes. It should not affect runtime performance. And I never see the
performance of a configuration class is a bottleneck.
Thanks,
Yunze
On Sun, May 7, 2023 at 8:49 PM tison <wander4...@gmail.com> wrote:
>
> > have a seamless performance improvement
>
> To be clear, it's an improvement for dev experience instead of runtime
> performance, right?
>
> Best,
> tison.
>
>
> Yunze Xu <y...@streamnative.io.invalid> 于2023年5月7日周日 20:25写道：
>
> > For now, I think we can use trivial getters and setters instead of
> > lombok generated getters and setters to have a seamless performance
> > improvement.
> >
> > Thanks,
> > Yunze
> >
> > On Sun, May 7, 2023 at 7:49 PM Yunze Xu <y...@streamnative.io> wrote:
> > >
> > > > creating a new class, and using it
> > >
> > > It's the commonly used way to handle breaking changes. Otherwise, we
> > > don't need any "deprecated" annotation or something else in various
> > > languages.
> > >
> > > > The biggest breakage would be the plugins no?
> > >
> > > Maybe. But any third party application that depends on the
> > > pulsar-broker module and sets up its own mocked Pulsar service could
> > > have a chance to modify the `ServiceConfiguration` via the setters.
> > >
> > > Thanks,
> > > Yunze
> > >
> > > On Sun, May 7, 2023 at 5:39 PM Asaf Mesika <asaf.mes...@gmail.com>
> > wrote:
> > > >
> > > > I like doing the split.
> > > > The biggest breakage would be the plugins no?
> > > >
> > > > I didn't understand creating a new class, and using it. Can you expand
> > on
> > > > it?
> > > >
> > > >
> > > > On Fri, May 5, 2023 at 11:44 AM Yunze Xu <y...@streamnative.io.invalid
> > >
> > > > wrote:
> > > >
> > > > > Oh, I figured out the reason finally. It's caused by the lombok.
> > After
> > > > > I changed all getters and setters with the trivial getters and
> > > > > setters, the completion time was reduced from 15 seconds to 2
> > seconds.
> > > > >
> > > > > Thanks,
> > > > > Yunze
> > > > >
> > > > > On Fri, May 5, 2023 at 4:30 PM Yunze Xu <y...@streamnative.io>
> > wrote:
> > > > > >
> > > > > > I think the configuration pojo is the issue. There are hundreds of
> > > > > > getters and setters. I did an experiment in my local env. First,
> > copy
> > > > > > `ServiceConfiguration` to another class named
> > > > > > `PulsarServiceConfiguration`. Then write the following code
> > > > > >
> > > > > > ```java
> > > > > > PulsarServiceConfiguration conf = new PulsarServiceConfiguration();
> > > > > > conf.
> > > > > > ```
> > > > > >
> > > > > > and see how much time it would take between typing the dot symbol
> > and
> > > > > > the popup window being shown on my Intellij Idea.
> > > > > >
> > > > > > - Default: about 15 seconds
> > > > > > - Remove the `@Getter`: about 5 seconds
> > > > > > - Remove the `@Setter`: about 4 seconds
> > > > > >
> > > > > > > one problem is that if split in this way, most config should
> > change
> > > > > access by conf.getLoadBalancerConfiguration().getXXXXX().
> > > > > >
> > > > > > It's unacceptable because it's a big breaking change. My idea is to
> > > > > > add another configuration class and mark `ServiceConfiguration` as
> > > > > > deprecated. Once a new config was added, add it to the new class.
> > > > > >
> > > > > > Thanks,
> > > > > > Yunze
> > > > > >
> > > > > > On Mon, May 1, 2023 at 2:13 PM Asaf Mesika <asaf.mes...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > The Config file size is the issue or the configuration pojo ?
> > > > > > >
> > > > > > > On Sun, 30 Apr 2023 at 19:51 lifepuzzlefun <wjl_is_...@163.com>
> > wrote:
> > > > > > >
> > > > > > > > current file is 3470 line with all pulsar configuration.
> > > > > > > > it is slow in my local ide.
> > > > > > > >
> > > > > > > >
> > > > > > > > 59 config in loadbalancer.
> > > > > > > > 17 config in metric.
> > > > > > > > 64 config in policies.
> > > > > > > > 41 config for bk client.
> > > > > > > > 50 for managed ledger.
> > > > > > > > 100+ for all other server cofig.
> > > > > > > >
> > > > > > > >
> > > > > > > > if split by category maybe more clear
> > > > > > > >
> > > > > > > >
> > > > > > > > class ServiceConfiguration {
> > > > > > > > LoadbalancerConfiguration
> > > > > > > > MetricConfiguration
> > > > > > > > BookkeeperClientConfiguration
> > > > > > > > ....
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > > one problem is that if split in this way, most config should
> > change
> > > > > access
> > > > > > > > by conf.getLoadBalancerConfiguration().getXXXXX().
> > > > > > > >
> > > > > > > >
> > > > > > > > so most of the code base will be changed.
> > > > > > > >
> > > > > > > >
> > > > > > > > any ideas ?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> >
