Open tanguycdls opened 2 years ago
Thanks for reporting this! The batch size decrease is definitely not expected and something that may be one of the reasons for slowdown. It is controlled by Apache Beam in beam.BatchElements. Would you be able/willing to test whether the performance gets better by locally modifying this to also have "min_batch_size": _BATCH_SIZE_CAP ?
As a side note, seeing that you do tf.RaggedTensor.from_sparse
I'm guessing that you have VarLenFeatures? If so, you could directly switch to RaggedTensors (and RaggedFeatures, now fully supported in TFT), this would make the mentioned Decode step and the preprocessing more efficient.
Hello, for testing reasons we wanted to see if approximate vocabulary was faster than vocabulary when there are many features (we have 36 features to analyze). In the past we hit the graph too large error in dataflow when using vocabulary (fixed using upload_graph but we still have some limits).
However in our comparison it's at least 4 times slower and we're not sure to understand why.
Here is our transform function: we reload the data using tfxio from a TF record dataset.
we replaced tft.vocabulary by tft.experimental.approximate_vocabulary.
Here our stats for vocab vs approximate vocab:
The CPU seems to peak very fast at 100% with 8 machines started but the throughput is way smaller.
and we use the following beamPipelineArgs:
Do you see a reason why approximate vocabulary would be that much slower than vocabulary here ? we tried reducing top_k but did not change much.
Thanks,