You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
performance issues of getting online features related to parsing protobuf data #3649
Is your feature request related to a problem? Please describe.
The profiler of one application I am working on shows the from_proto method of the FeatureView class takes up 80% of the execution time. The result of cProfile is shown below.
There are 3 feature views accessed by get_xxxx_features, however 100 calls of get_xxxx_features lead to 3500 calls of from_proto. There are 17 feature views in the feature store of this application and 3 of them are used by get_xxxx_features.
Environment: continuumio/miniconda3:4.11.0 (linux/amd64) base image, python==3.9.7, feast=0.31.1, protobuf==4.23.2
Describe the solution you'd like
Instead of caching the protobuf blob of FeatureView, cache the FeatureView python object in memory.
so that the application developer has the option to cache the FeatureView objects and use them to get features directly (by passing the get_feature_views_to_usestep )
From here, get_feature_views_to_use doesn't seem like a good idea to cache this because the feature_views to use changes depending on input argument features.
What I found is, if feature registry has not expired, I assume that the registry.list_* methods always return the same result. Currently, this isn't cached, so list_* methods are being called every time, and from_proto in them is being called repeatedly and it makes get_online_features slow.
(list_* methods mean registry.list_feature_views, registry.list_data_sources ...)
So, my idea is to process the list_* methods using cached results when the registry is not expired.
When using the sql registry, as you can see in the code above, the registry is updated by checking whether it has expired. Using this expired will tell us whether to return cached results. And I believe that caching this registry in memory would be no problem.
Activity
goodseog commentedon Jun 14, 2023
I'm facing the same issue too.
From here,
get_feature_views_to_usedoesn't seem like a good idea to cache this because the feature_views to use changes depending on input argumentfeatures.feast/sdk/python/feast/feature_store.py
Lines 2149 to 2154 in c474ccd
What I found is, if feature registry has not expired, I assume that the
registry.list_*methods always return the same result. Currently, this isn't cached, solist_*methods are being called every time, andfrom_protoin them is being called repeatedly and it makesget_online_featuresslow.(
list_*methods meanregistry.list_feature_views,registry.list_data_sources...)So, my idea is to process the list_* methods using cached results when the registry is not expired.
feast/sdk/python/feast/infra/registry/sql.py
Lines 244 to 259 in c474ccd
When using the sql registry, as you can see in the code above, the registry is updated by checking whether it has expired. Using this expired will tell us whether to return cached results. And I believe that caching this registry in memory would be no problem.
goodseog commentedon Jun 14, 2023
or caching these fvs, request_fvs, od_fvs!
feast/sdk/python/feast/feature_store.py
Lines 2149 to 2177 in c474ccd